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Abstract 


This document describes the development of distributed object applications with 
VisualAge and System Object Model. It provides guidelines for applying the 
Visual Modeling Technique (VMT) developed at the ITSO San Jose Center to 
application modeling, design, and implementation in a distributed object 
environment. The guidelines are illustrated with a foreign currency exchange 
banking application. 

This document is written for software development managers, software 
designers, and application developers who plan to develop distributed object 
applications using VisualAge. Some knowledge of object modeling and the 
VisualAge product is assumed. 

(225 pages) 
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Preface 


This document describes the process of building a distributed object application 
by using VisualAge for Smalltalk, VisualAge C++, and the SOMobjects 
Developer Toolkit. 

It contains: 

• A description of the distributed object environment, as defined by the OMG's 
CORBA specifications, and its implementation through IBM SOM/DSOM 

• The modeling process in developing a distributed object application, using 
the Visual Modeling Technique (VMT) developed at the IBM ITSO San Jose 
Center 

• The design and implementation of the sample Foreign Currency Exchange 
(FCE) application using VisualAge and SOMobjects 

• Recommendations for building distributed object applications with VisualAge 
and SOM/DSOM. 

This document is written for software engineers, application engineers, 
application programmers, software development managers, and object 
technology consultants. 


How This Document Is Organized 

The document is organized as follows: 

Part 1 : Introduction 

• Chapter 1. Introduction to Distributed Systems 

This chapter provides an overview of distributed systems, Client/Server 
computing and the emerging distributed object applications. 

• Chapter 2. Distributed Object Systems 

This chapter provides an introduction to distributed object systems. It 
shows the general trend moving toward distributed object computing. It 
explains how object technology can be applied to develop distributed . 
application systems. 

• Chapter 3. Industry Standards 

This chapter provides an introduction to the CORBA standard defined by 
the Object Management Group, and SOM, the IBM implementation of 
CORBA. 

• Chapter 4. IBM System Object Model 

This chapter describes the IBM SOM and DSOM Technology, as well as 
the SOMobject product. 

• Chapter 5. IBM Distributed Smalltalk Technology 

This chapter describes the IBM Distributed Smalltalk Technology, and its 
coexistence capability with DSOM. 

• Chapter 6. Implementation Alternatives with SOMobjects 
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This chapter describes the implementation of SOM servers by writing IDL 
statements and compares it with the direct-to-SOM facilities of C++ 
compilers. 

Part 2. Developing a Distributed Object-Oriented Application 

• Chapter 7. The Foreign Currency Exchange Case Study 

This chapter describes the objectives, requirements for building the 
foreign currency exchange sample application. 

• Chapter 8. Analyzing the FCE System 

This chapter reviews the analysis work done in a non-distributed FCE 
case study application. Many of the analysis work can be reused in 
developing a distributed solution. 

• Chapter 9. Designing the FCE Application with Distributed Objects 

This chapter provides the design details in extending the FCE application 
using distributed objects. 

• Chapter 10. Implementing the Distributed FCE Application 

This chapter describes the implementation of the distributed FCE sample 
application, using VisualAge Smalltalk SOM support and VisualAge 
C + + compiler. 

• Chapter 11. Looking Ahead 

This chapter summarizes the requirements and trends in distributed 
object application development. 

• Appendix A. Requirements Specifications 

This appendix describes the requirements for building the FCE 
application. 

• Appendix B. Setting Up the Implementation Platforms 

This appendix describes the client/server environment and tools used for 
building the distributed FCE sample application. 

• Appendix C. FCE Data Base Definition 

This appendix describes the definitions for the relational data bases used 
in the sample FCE application. 

• Appendix D. SOM IDL Interface Listings 

This appendix describes the definitions used to define the server 
components with DSOM. 

• Appendix E. SOM Objects Implementation Files 

This appendix lists the SOM objects implementation code used for the 
FCE application. 


Related Publications 
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more detailed discussion of the topics covered in this document. 

• Object-Oriented Application Development with VisualAge in a Client/Server 
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International Technical Support Organization 

The IBM International Technical Support Organization (ITSO) is a unique group 
within IBM. The ITSO consists of seven centers located at major product 
development sites: 

• Austin 

• Boca Raton 

• Boblingen 

• Poughkeepsie 

• Raleigh 

• Rochester 

• San Jose 

The mission of the ITSO is to provide how-to technical support for IBM products 
worldwide. Each center works closely with the development organizations to 
provide support for the products developed at their locations. In addition, the 
centers work together to provide cross-product and cross-platform support with a 
total system solution perspective. 

Technical bulletins such as the one you are reading, commonly known as 
redbooks, are produced by the ITSO centers as one of their primary vehicles for 
delivering technical product information to customers and IBM field personnel. 
These redbooks are typically the result of several months of effort involving 
multiple IBM residents from around the world. The residents bring their 
technical expertise and knowledge of their customer's environment to the ITSO 
centers and spend 6 to 8 weeks testing the product and documentation. Their 
experiences and findings are then published in a redbook. 

Redbooks are not intended to replace product documentation; rather they 
supplement the documentation with actual user experiences. Because the 
residents work with development to better understand the products, the IBM 
development organizations are better able to understand user requirements. 

The ITSO centers also produce workshops and other deliverables designed to 
provide technical information to those who use and support IBM products. 

We hope you find this and other ITSO redbooks useful and that you will make 
them an integral part of your systems library. Please take the time to fill out the 
enclosed evaluation form and let us know what you think. 

You can send comments or questions regarding this redbook by electronic mail 
to: 

Walter Fang 
ITSO-San Jose Center 

Internet: fangwiavnet.ibm.com 
IBM VNET: FANGW at WTSCPOK 
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Part 1. Introduction 


Part 1 introduces distributed systems and explains the challenges of and 
approaches to developing them. Several options in the basic design of a 
distributed system are presented. 

Part 1 also provides an overview of the Common Object Request Broker 
Architecture (CORBA) standard defined by the Object Management Group (OMG) 
and the IBM implementation of a CORBA-compliant object request broker 
through Distributed SOM (DSOM). 
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Chapter 1. Distributed Systems 

The computing industry is embarking on one of the most drastic technological 
transformations of the decade: the transition from a traditional computing 
infrastructure and its application development techniques to a new, 
distributed-object computing infrastructure. 

In this chapter we review the fundamental concepts of distributed systems and 
Client/Server computing. We explain the benefits and challenges associated 
with distributed application development. 

A distributed system is a collection of autonomous computers connected by 
some type of network. Distributed systems offer a number of advantages over 
single-processor systems: 

• Several computing elements are available in the system. If an application is 
decomposed into pieces that run concurrently, the application will run faster 
and yield more throughput. 

• Fewer users compete for resources on different computers, thus reducing 
contention and response time variability during peak hours. 

• Overall availability is higher because the computers in a distributed system 
have independent failure characteristics. The failure of any single computer 
affects only the users of that computer. Availability of critical data can be 
ensured by replicating the data at server nodes. 

• Scalability is improved. The total system can be configured with great 
flexibility. Nodes can be: 

- Added to or removed from the network. 

- Reconfigured to meet changing requirements. For example: 

- Disks can be moved from one node to another. 

- Data can be moved from one node to another. 

- Data can be replicated at several nodes. 

- Made more or less powerful. For instance, a node can be replaced by a 
multiprocessor node to increase its processing power. 

The scalability of distributed systems is in sharp contrast to the limited 
growth potential of traditional mainframe computers. 

1.1.1 Client/Server Computing Model 

The Client/Server computing model is widely used in a distributed system. The 
model defines two separate parts of a Client/Server application (see Figure 1 on 
page 4): 

• The client (for example, an application running on a workstation) calls for 
services, such as data or processing functions. 

• The server performs services on behalf of the calling client. The server can 
be a program, located on the same machine as the client, or it can run on a 
remote machine, even on a different operating system from that of the client 
machine. 
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Figure 1 . Client/Server Computing Model 

In the Client/Server computing model, the client application does not have to 
distinguish between local and remote services. The programming complexities 
of network distribution are transparent to the client application, regardless of 
whether they are handled by the called service or the calling mechanism. Thus, 
the client application need not care about the location of services or the 
interconnection media. 

The Client/Server model is inherently capable of providing resource sharing. A 
server can, for instance, provide access to data that resides on fast disks. It can 
improve data access further by using large cache buffers in memory. These 
expensive resources are made available to many client applications through 
Client/Server computing. 


1.1.2 Client/Server Styles 

Figure 2 on page 5 shows the distribution of functional parts of an application. 
Everything from the presentation (the front end, that is, the GUI) to the business 
logic (the back end) can be flexibly placed on different nodes in a distributed 
environment. The Client/Server computing styles shown in Figure 2 on page 5 
have a direct impact on the complexity, portability, and reliability of a distributed 
application. 
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Figure 2. Client/Server Computing Styles 


1.2 Challenges in Building Distributed Systems 

Distributed systems present interesting functional capabilities. However, their 
implementation presents several challenges: 


• Partial and independent failures 

Because parts of an application run on different computers, it is possible that 
some parts will fail while others proceed. Partial failure lead to inconsistent 
states of the program. For example, when money is debited from an account 
on one computer to be deposited in an account on another computer, if the 
computer responsible for the deposit fails, what should be done with the 
money already removed from the source account? The application 
developer or administrator must be able to cope with such partial failures, 
possibly by stopping the functioning parts of an application and undoing 
some of their earlier effects. 

• Concurrent and independent events 

Many things that can be assumed in a single-processor environment do not 
apply to a distributed environment where independent computing entities are 
active. Concurrent and independent events have to be synchronized. A 
common way of ensuring atomicity of an action when one has to update 
shared data is to obtain a lock, apply the update, and then return the lock, to 
allow others to update the data. Overall, controlling access to shared 
resources is more difficult in a distributed computing environment. 

• Site autonomy 

There is a trade-off between making each node independent or integrating 
all modes in a “single system.” The advantage of integrating nodes is that 
the user can continue to use the system even if other nodes fail. The 
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disadvantage is that sharing and cooperation are harder to achieve. The 
advantage of integrating all nodes into one single system is that sharing and 
cooperation among users are facilitated, and one node can be used to 
provide such services as backup for another node. The disadvantage is 
increased interdependence of nodes on one another. If we introduce too 
much interdependence, the failure of one node may affect the rest of the 
system and its users. The extent of site autonomy can be determined by 
asking to what extent will a user taking his or her machine off the network 
affect the rest of the system and its users. 

• Heterogeneity 

The maximum advantage of scalability in distributed systems can be 
achieved only if the nodes on the network can be different from one another, 
and applications can use the most appropriate nodes for each function they 
perform. We can imagine having nodes with different system configurations 
(for example, DASD, memory), which could be termed heterogeneous. More 
challenging is the integration of heterogeneous processors, operating 
systems, or programming languages. A distributed system could, for 
example, support nodes that are models of the same machine but run the 
same operating system. More difficult are systems that support nodes 
running different operating systems. Still more difficult are systems that 
could support an application written in multiple languages running on 
different processors and operating systems. 

• Security 

The geographical distribution of the nodes in a distributed system introduces 
security risks that do not exist with a time-shared system locked in a 
computer room. Approaches to solving these problems include password 
mechanisms and data encryption for stored data and messages, are being 
addressed. The Open Software Foundation Distributed Computing 
Environment (OSF DCE) addresses the security aspects of distributed 
systems. 


1.3 Approaches to Building Distributed Systems 

Several approaches to building distributed systems are described below. 

• Distributed Operating System 

The distributed operating system provides the programmer with a 
single-system image. A program running on top of a distributed operating 
system sees a collection of resources and services that it can use without 
any concern for whether the resources and services are actually available at 
the node at which it is running. The advantage of the distributed operating 
system approach is that the effort of dealing with distribution issues is paid 
only once, when the operating system is written. The disadvantage is that a 
distributed operating system requires the different nodes to be homogeneous 
nodes running the same level of the operating system. 

• Networked Operating System 

In a networked operating system each node runs an independent operating 
system. Each operating system, however, provides a network interface, 
which application programs can use to communicate with other nodes. 
Because the network interface is supported “on top” of the operating 
system, this approach can accommodate heterogeneous operating systems 
(and hence, processors). 
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• Distributed File System 

In a distributed file system, a node can mount a file system from another 
node at boot time or at request. In this way the node will have access to the 
remote file system. The disadvantage of this approach is that each 
application program has to deal with issues of distribution. 

• Distributed Programming Language 

The distributed programming language approach supports the notion of 
distribution in the programming language. Here the programming language 
implementation of the run-time system is responsible for dealing with 
distribution issues. If the abstraction of nodes and remote resources is 
provided in the programming language, the application can access remote 
resources directly. Alternatively, the programming language can try to make 
the network transparent, much like a distributed operating system makes it 
transparent. The advantage of this approach is that the language can be 
implemented on different operating systems and therefore can support a 
network of heterogeneous processors. The disadvantage is that it is complex 
to design a distributed programming language. 

• Distributed Programming Toolkit 

The distributed programming toolkit approach is somewhere between a 
networked operating system and a distributed programming language. It 
provides a library (toolkit) of routines that aid in the writing of distributed 
applications. These routines can provide mechanisms for communication, 
synchronization, failure detection, and recovery. This approach is at a higher 
level of abstraction than the networked operating system approach but at a 
lower level than the distributed programming language approach. When 
there is no single appropriate abstraction for distributed programming, the 
toolkit approach is appealing because a toolkit can contain many different 
tools. Examples are IBM's Distributed SOM (DSOM), OSF's DCE remote 
procedure call (RPC), and Sun's Network Computing System (NCS). 


1.4 Examples of Distributed Systems 

The following are some examples of distributed systems: 

• Remote directories 

A user logged on to one node can see a global directory tree with directories 
maintained on different nodes. The Network File System (NFS) and the OSF's 
DCE distributed file system (DFS) are examples of remote directories. 

• Distributed run-time library 

A distributed run-time library enables users to write applications without 
concern for the location of files and interprocessor communication. The 
library intercepts accesses to nonlocal files and forwards them to the correct 
destination node. 

• Specialized servers 

Users work at their personal workstations, which supply most of their 
computing needs. Specialized needs, such as file storage or gateway 
access, are provided by nodes on the network. 

• Processor pool 
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Processing power is just another service; the user's need for such a service 
is variable over time. Most of the time users are satisfied with the 
processing power available on their workstations. Sometimes, however, such 
as when they want to run a large simulation, they need a large amount of 
processing power. Thus one or more processors from a pool can be 
allocated to a user and taken away when the processor-intensive application 
is finished. Processor pools are a good way of sharing processing power and 
distributing the computational load of the system. 


1.5 Data and Function Placement 

In designing distributed systems, a key design consideration is the placement 
and distribution of function and data. One important design aspect for 
distributed systems is how to share and manage data to ensure its integrity. 
Equally important is the placement of the control and processing functions in the 
distributed systems to achieve optimal resource utilization and to maximize 
overall system performance. 

We discuss the basic data and function distribution strategies in the sections that 
follow. 

1.5.1 Data Distribution 

Data in a distributed environment can be managed through centralization, 
replication, or partitioning: 

• Centralized data management 

The data is placed at one node, and all accesses to that data are routed to 
that node. 

• Replicated data management 

Copies of data are made at various nodes. The nodes needing access to the 
data can access the “closest” node. 

• Partitioned data management 

The data can be partitioned into pieces, and the pieces can be placed at the 
various nodes. Accesses to the data must be routed to the appropriate node 
according to which piece of the data is being accessed. 

These three techniques of data management in a distributed environment apply 
equally well to the management of processing and control functions. Thus, 
processing and control functions, as well as data, can be centralized, replicated, 
or partitioned. 

1. 5.1.1 Centralized Data 

Consider the case of workstations connected on a local area network (LAN; see 
Figure 3 on page 9). A list of users is kept for authentication purposes. The list 
is accessed at login time. A single copy of the list is kept at a central location, 
such as a large computer that all workstations can access. 
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Figure 3. Centralized Data Management 

The advantage of centralized data management is that, by maintaining a single 
copy of the data, the login information can be modified in one place. The 
disadvantage is that each login results in a message between the workstation 
and the host site where the login file resides. Furthermore, if the host site is 
nonoperational, users cannot log in at any of the workstations. There is both a 
performance and an availability disadvantage with maintaining a central login 
file. 

1.5. 1.2 Replicated Data 

A circumvention of the problems of centralized data management is to have 
copies, or replicas, of the login file at multiple nodes (see Figure 4). 



Figure 4. Replicated Data Management 

Flaving multiple copies solves both the performance and availability problems of 
centralized data management. The performance problem is solved because 
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accesses to the login file are local and not remote. The availability problem is 
solved because it is easier to find an available copy of the login file when there 
are several copies of it. In addition, concurrent accesses at multiple workstations 
improve throughput. 

The disadvantage of replicated copies is the new problem (and cost) of ensuring 
the consistency of the replicated data. There are many different ways of solving 
the consistency problem. The level of difficulty and the performance of the 
algorithm depend on the relative ratio of read operations to write operations 
against the replicated data. In our example of replicating the login file, accesses 
at login time pose no problem because they are read-only. If the login file is 
modified, however, one has to ensure that the modifications are distributed to all 
copies and that inconsistent modifications are not made at different sites. If the 
number of read accesses is much larger than the number of write accesses, 
which is the case with the login file, replication is advisable. 

One way of ensuring the consistency of replicated data is to lock all copies when 
an update is attempted. Only after all copies have been locked will an update to 
the file be allowed. After the update takes place, it is propagated to the different 
copies. This approach decreases the amount of concurrency, however, because 
logins are not allowed during locking and propagation of the update. The basic 
trade-off in replication techniques is to support the highest amount of 
concurrency while providing the highest availability of up-to-date data. 

1 .5.1.3 Partitioned Data 

Instead of replicating the login file, another approach to solving the performance 
and availability problems of centralized data management is to partition or 
distribute the contents of the file (see Figure 5). 
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Figure 5. Partitioned Data Management 


In the case of a network of, say, 10 workstations, one could partition the login file 
into 10 files, each one-tenth in size. The collection would be “the login file.” This 
solution helps login performance because it is likely that user authentication will 
be distributed throughout the network rather than through the same node. This 
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approach also supports partial availability because the unavailability of any 
single node only disallows one-tenth of the users from logging in. As in the case 
of data replication, there is some overhead at both data retrieval and update 
time. The correct partition to address data retrieval and update needs has to be 
determined. One possible way of partitioning the data is to have the data 
located near the nodes where it will be used most often. A typical example is a 
distributed database of bank accounts where the account information database is 
partitioned according to the geographical location of the owner of the account. 

One can distinguish between horizontal and vertical partitioning. With horizontal 
partitioning, partitioning is on the unit of tables. With vertical partitioning, 
partitioning is within tables (that is, the customer table is divided into tables 
containing contiguous sets of customers). 

1.5.2 Function Distribution 

Processing and control functions can be centralized, replicated, or partitioned in 
much the same way as data. 

1.5. 2.1 Centralized Processing 

With central processing of user login requests, the login service is at a single 
node (see Figure 6). 
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Figure 6. Centralized Processing 


1. 5.2.2 Replicated Processing 

With replicated processing of user login requests, the login service is replicated 
at several nodes (see Figure 7 on page 12). 
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Figure 7 . Replicated Processing 


1. 5.2.3 Partitioned Processing 

With partitioned processing of user login requests, the login service is 
partitioned such that each node is capable of processing certain login requests 
(see Figure 8). 
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Figure 8. Partitioned Processing 

Although centralized and partitioned login processing may not make too much 
sense, there are other examples where it is useful to consider replicating or 
partitioning functions independent of the data configurations. In a database 
application, a single node could be designated to process all functions in order 
to minimize the problems of dealing with contentions and locking; or some 
nodes might be allowed to perform lookup requests while other nodes would be 
charged with permitting update requests. Also one might consider replicating the 
function processing at several nodes in order to increase the concurrency 
handling capabilities of the system. 
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In summary, if the main interest is a resilient service, centralization of the 
processing function is not the best approach. Instead, choose replication, 
partitioning, or a combination of both, depending on the amount of concurrency 
or availability in which you are interested. We have discussed the configuration 
of data and processing functions independently; in reality, however, the 
decisions regarding data and processing are closely related. For example, if you 
choose data partitioning, choose partitioned processing as well. 

Although replication of data is the basis of providing data availability in 
distributed systems, and replicated processing is the basis of reducing 
contention and providing higher throughput, centralized data and centralized 
processing are easier to implement. 
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Chapter 2. Distributed Object Applications 

In this chapter, we explain the relationship of object-oriented techniques to 
distributed application development, with specific regard to the extent to which 
object-oriented techniques help distribution. 

We show the shift in computing infrastructure as well as how the development of 
distributed applications based on object technology exploits the latest distributed 
object computing technology. Generally, just as object-oriented design and 
programming have helped to improve productivity of nondistributed software 
development, they also help improve productivity in distributed software 
development. 


2.1 Distributed Object Computing 

With the trend toward reducing computing costs by rightsizing (which implies 
distributed processing), developers must design their applications to run on 
networks of interconnected machines that share the processing load. 

Applications must make the best use of existing resources to meet the needs of 
business and achieve performance, scalability, security, usability, and 
maintainability objectives. 

Today's businesses are also finding the traditional Client/Server approach to be 
inefficient. Typically, most application logic in a Client/Server environment is 
located on the client machines, with centralized or distributed database servers. 
This approach can lead to excessive network traffic and difficulty in maintenance. 
One solution to these problems is to put some of the application logic on the 
server where it can access the data locally. This requires an approach much 
more flexible than the traditional Client/Server approach. 

The new approach is called distributed object computing , that is, objects are on 
the server as well as on the client machines. After all, object-orientation and 
Client/Server computing build on similar concepts: 

Client/Server 

• Client requests a service. 

• Server fulfills that request. 

Object-orientation 

• Client (sender) object sends a message to request a service. 

• Server (receiver) object responds and acts on the message. 

Figure 9 on page 16 shows an object model and the communication of objects 
through messages. 
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Distributed object computing extends this model and enables developers to 
assemble applications from objects that run on disparate platforms distributed in 
a network. Objects communicate with each other through a message-passing 
mechanism. An object's role can change between client and server. A given 
object can act as a server to some objects and, at the same time, as a client of 
other objects. Furthermore, the client and server objects can be on the same 
machine and even in the same business process. 

2.1.1 Distributed Objects 

On the surface, object-oriented design seems ideally suited for distributed 
systems because the notion of objects provides a convenient mechanism for 
encapsulating data and function. Just as objects can be used as decomposition 
units they also can be used as units of distribution. A problem arises, however, 
in the following case: if one were to cache data from a remote object and make 
it available to a local object, the encapsulation, as defined by object-oriented 
technology, is broken. A second problem is the handling of concurrency and 
concurrency control. 

Configuration of data and processing with object-oriented technology are 
intimately related. Although processing and data could be looked at separately 
from a logical point of view, an object is actually processing and data combined. 
When a database is used to store the state of the object, all data configurations 
mentioned above — centralized, partitioned, and distributed — apply equally. An 
object could be constructed from state (data) residing at a different node. In the 
case of using proxy objects (a proxy object is a stand-in object for another 
object), where the invocation of the process is replicated and the execution of 
the process is centralized, processing is in reality partitioned. The process 
invocation and method dispatching are executed locally, and the actual 
execution of the method is done at a different node. 
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2.1.2 Evolution of Client/Server Implementation with Objects 

Figure 10 demonstrates the evolution of Client/Server implementation with 
objects. Object-oriented technology has started to move into the Client/Server 
realm, primarily on the client side. Eventually, we will reach the right-most 
configuration where objects are a common feature of client and server alike. 



The benefits that object-oriented technology has brought to client programming 
apply equally well to the server side. Perhaps most important is the ability to 
manage complexity and change. The multiuser requirements and greatly 
magnified scale of the server side naturally lend themselves to complexity, 
which creates a need for the encapsulation, reusability, and the close mapping 
between the problem and solution domains that object-oriented technology 
makes possible. 

Data will be encapsulated in objects that will in some cases be able to roam to 
where they are most needed. 

(Peter Wayner, Byte Magazine, 01/94) 

Using encapsulation and reusability with object-oriented technology also helps to 
manage system changes. They enable server programmers to isolate changes 
and minimize maintenance costs. The close mapping between the problem and 
solution domains enables one to model the enterprise and then build an 
implementation that maps directly to the enterprise. This ensures that the 
changes are made quickly and correctly. Today's business environment creates 
pressure for information systems flexible enough to cope with the rapid pace of 
change. Such flexibility is difficult to manage on the server level, as evidenced 
by the pervasive IS backlogs. Benefits such as those offered by object-oriented 
technology are greatly needed. 

Despite the potential advantages, however, to date there have been few 
successful object-oriented server implementations. One reason is an old story 
in the industry: critical mass. An organization cannot afford to maintain an 
entire proprietary object-oriented programming language or server environment 
just for its own use, and tool developers are hesitant to develop the needed tools 
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until there is a proven market for them. However, as tool providers converge on 
architectural and language standards, costs can be spread among many users. 

As Orfali [Orfali94] points out, we are within the third wave of Client/Server 
technology as shown in Figure 11. The first wave, which started in the early 
1980s, came with network operating systems that allowed applications to share 
files, printers, and other networked devices. The second wave, which began in 
the mid 1980s, introduced SQL database servers into Client/Server applications. 
Along with that trend, groupware and transaction processing (TP) monitors such 
as CICS OS/2 gained a solid piece of the Client/Server cake. The third wave, 
which began in the early 1990s, is the distributed objects wave. The distributed 
objects wave is still at a moderate height, but we should start to swim now so 
we can follow that wave up to its crest! 

Distributed object computing represents a new and exciting trend to merge two 
powerful technologies in the information industry: Client/Server computing and 
object-oriented technology. 


First Wave Second Wave Third Wave 



1982 1986 1990 1994 1998 


Figure 11. Waves of Client/Server Technology 

This architecture holds significant promise for tomorrow's distributed 
applications. 


2.2 Applicability of Distributed Objects 

In this section we describe three kinds of applications that are suitable for 
distributed objects: object server, active server, and peer-to-peer (see Figure 12 
on page 19). These applications raise a new set of requirements that can be 
better addressed by a distributed object solution than by the traditional 
Client/Server approach. 
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Figure 12. The Changing Role of the Server 


2.2.1 Object Server 

The most common Client/Server implementations today use the remote data 
access style, in which all ot the business logic is on the client systems. The client 
systems become the so-called fat clients, accessing a remote relational 
database server. 

Using the existing Distributed Relational Database Architecture (DRDA), client 
workstations can access a centralized database through the SQL interface 
across the network. However, this approach can lead to excessive network traffic 
between the clients and the relational database server. This is especially true 
when we have to retrieve many intermediate results from the database server in 
order to accomplish one task on the client. 

In a fat client situation, the data server does not filter any information it retrieves 
from the databases, normally in the form of rows of data tables, before sending it 
to the client. Therefore it generates unnecessary network traffic. 

One way to reduce the network traffic is to use stored procedures, which many 
relational database products support. A stored procedure is a named collection 
of SQL statements and procedural logic that is compiled, verified, and stored in 
the database server. The problem with stored procedures is that there is no 
standard for them, and they only work for local databases. Each relational 
database vendor has its own implementation of stored procedures. Thus it is 
very difficult, if not impossible, to use stored procedures to access multiple 
databases from different vendors in a single client task. 
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As shown in Figure 13 on page 20, to avoid excessive network traffic, we could 
put more processing functions in the server, in addition to its traditional data 
access role. The server then becomes an object server. Instead of using the 
SQL interface between the client and the server, the clients issue the request to 
the server in the form of the required objects. By massaging the data and 
constructing the requested objects at the server before sending them to the 
client, we can reduce the network traffic, improve overall application 
performance, and potentially reduce the number of requests that the client has 
to send to the server. 


Data Server 


Client Server 




Object Server 


Client 


Server 



Figure 13. Object Server 


A side benefit of this approach is that we do not have to have the relational 
database software installed in the client workstations. In an operational 
environment with large numbers of clients, substantial savings could be gained 
from not having to pay license costs for the client workstations. 


2.2.2 Active Server 

In a traditional Client/Server computing model, the client always originates the 
requests. The server is passive in the sense that it only reacts to the client's 
requests. We can change the way the server behaves in this model so that the 
server is an active party in the system. This is what we call an active server. The 
server can process data by itself and initiate the communication with clients. 

We can look at an example of an active server in a publisher-subscriber 
scenario (see Figure 14 on page 21). The server publishes events that it can 
handle, and clients can then subscribe to those events in which they are 
interested. Let us say that a stockbroker is interested in the current prices of 
some specific stocks. In an active server environment, the stockbroker can ask 
the server for the available (published) share prices and then choose (subscribe) 


20 Developing Distributed Object Applications 




those stocks that are needed. Whenever the price of a subscribed-to stock 
changes, the subscriber is notified automatically. 


SERVER 



Figure 14. Active Server: Publisher/Subcriber Scenario 

Another active server example is an auctioneer at an auction. The auctioneer 
starts the event and keeps track of the bidding. Bidders (clients) can send their 
bid to the auctioneer (server) who holds the current highest bid price and the 
name of the bidder. All bidders are notified whenever the situation changes. 

2.2.3 Peer-to-Peer 

In peer-to-peer applications (Figure 15), two client workstations communicate 
with each other directly, acting both as a server and a client at the same time. 
Peer-to-peer applications can be useful, for example, when two users on 
different client workstations have to establish a session for consultation or 
negotiation on a certain subject matter. 



Figure 15. Peer-to-Peer Application 
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In a traditional Client/Server computing model, communication between two 
clients is through the server. Two separate concurrent sessions must be 
established between each client and the server, thus causing more overhead on 
the network and the server. Instead, we want to have a direct communication 
link between the two clients so that they can establish a session whenever they 
want, without going through the server. 
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Chapter 3. Industry Standards 


In this chapter, we review the emerging standards and architectures for 
object-to-object communication and interoperability in a heterogeneous 
environment. 

As with any new technology, standards are required for object-oriented server 
technology to gain widespread acceptance; such standards are increasingly 
evident. Object Management Group's (OMG's) Common Object Request Broker 
Architecture (CORBA) standard has come to provide the basis for the Object 
Transaction Service (OTS) distributed object architecture, also defined by the 
OMG. In addition, two distributed transaction standards with object-oriented 
implications are widely recognized: the X/Open Distributed Transaction 
Processing (DTP) model and the ISO Open Systems Interface Transaction 
Processing (OSI-TP) standard. 

Standardization of programming languages is equally essential. In recent years, 
the industry has begun to converge on C++, Smalltalk, and object-oriented 
COBOL as standard industrial-strength object-oriented languages. 

Standards can help to ensure that objects developed using different vendors' 
tools are mutually compatible. As software vendors develop object-oriented 
components that conform to these standards for the server, customer confidence 
will continue to grow and customers will increasingly adopt the object 
technology. 


3.1 The Object Management Group 

Object-oriented business applications and the promised benefits of mass 
customization of software, rapid implementation, and reusability are obvious 
industry goals. To achieve those goals, the complexities of distributing objects 
across networks must be solved. Most vendor implementations today primarily 
support objects implemented on a single system. Those customers who are 
beginning to work with objects across the network find that a background in 
Client/Server and wide-area transactional processing is essential. The basic 
design points for distributed objects are very similar to things learned from old 
online transaction systems. You want to minimize the data that is transmitted 
and server processing time. Because many object approaches today were 
designed for a single desktop, they do not scale. The OMG is dealing with the 
technology issues related to distributing objects. Many of the design issues will 
be addressed as the collective experience base grows within the industry and as 
everyone learns from past lessons. 

The OMG is an industrywide, nonprofit consortium of more than 500 members, 
including Apple, AT&T, HP, IBM, Microsoft, and Sun. OMG was formed to help 
reduce the complexity, lower the costs, and hasten the introduction of new 
software applications. OMG does this by introducing its Object Management 
Architecture (OMA) with supporting detailed interface specifications. This single 
architecture and set of specifications based on commercially available object 
technology has been developed to enable the integration of distributed 
applications. Implementations are the domain of vendors, end users, and those 
developing products and projects to solve a particular computing or business 
problem. Specifications are the domain of OMG membership. 


© Copyright IBM Corp. 1996 


23 



The mission of OMG is to create a standard that realizes interoperability 
between independently developed applications across heterogeneous networks 
of computers. The goal is to achieve reusability of components, interoperability 
among heterogeneous platforms, and portability of applications based on open, 
standard, object-oriented interfaces. To that end, OMG has defined the 
architecture of an object request broker (ORB) that enables interoperability. This 
architecture is known as CORBA. 


3.2 Object Management Architecture 

The OMA (Figure 16) is the center of all activities undertaken by the OMG. 

To support heterogeneous, distributed, networked environments, the OMA 
combines distributed processing with object-oriented computing. It provides a 
standard method for creating, preserving, locating, and communicating with 
objects, which can be anything from complete application systems to parts of 
applications. The OMA defines a layer above existing operating systems and 
communication transport mechanisms. 

In the OMA's generalized object model, requests for object services are sent to 
the ORB. The requester can specify providers or alternative providers or leave 
the selection of a provider to the ORB. The model provides a common interface 
for objects of different origins. All client requests are issued in a standard 
format, improving modularity and decreasing coupling among modules. The 
OMA defines the mechanism that allows client objects to issue requests to and 
receive responses from OMA-conforming objects. 


"CORBAfacilities" 



Figure 16. Object Management Architecture Components 


24 Developing Distributed Object Applications 





3.2.1 OMA Reference Model 

The OMA Reference Model partitions the OMG problem space into practical, 
high-level architectural components that can be addressed by technology 
proposers. It forms a conceptual roadmap for assembling the resultant 
technologies while allowing for different design solutions. The Reference Model 
identifies and characterizes the components, interfaces, and protocols that 
compose the OMA but does not in itself define them in detail. 

The OMA can be viewed as two major segments consisting of four critical 
components (see Figure 16 on page 24): 

• Application oriented - the OMA characterizes application objects and 
common facilities as solution-specific components that rest closest to the 
end user. 

• System oriented - the ORB and object services are concerned with the 
system or infrastructure aspects of distributed object computing and 
management. 

The ORB manages all communications among components. The ORB technology 
is now considered the most important approach for deploying open, distributed, 
computing solutions. 

The OMA assumes that underlying services provided by a platform's operating 
system and lower-level basic services, such as network computing facilities, are 
available and usable by OMA implementations. 

3.2.2 OMA Components 

Figure 16 on page 24 shows the components of the OMA. Objects that belong to 
one of these components have their interface described with OMG's Interface 
Definition Language ( I D L) . This ensures that objects, implemented by different 
vendors, can communicate. Interfaces for application objects, however, are not 
and will not be standardized by OMG. We can define the OMA components as 
follows: 

• The ORB provides an infrastructure that enables objects to converse, 
independent of the specific platforms and techniques used to implement the 
objects. Compliance with the ORB standard guarantees portability and 
interoperability of objects over a network of heterogeneous systems. The 
official OMG name for the ORB is CORBA. 

• Object services extend the ORB by standardizing additional services 
required to fulfill the general needs of object applications. An example of an 
object service is the Life-Cycle Service, which is responsible for the life-cycle 
management of objects. The Life-Cycle Service describes interfaces to 
create objects, control access to objects, keep track of relocated objects, and 
to control the relationship between styles of objects (class management). 

Also provided are the generic environments in which single objects can 
perform their tasks. Object services provide for application consistency and 
help to increase programmer productivity. The official OMG name for object 
services is CORBAservices. 

• Common facilities provide a set of generic application functions that can be 
configured to the specific requirements of a particular configuration. The 
common facilities include printing, document management, database, and 
electronic mail. Standardization leads to uniformity in generic operations and 
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better options for end users for configuring their working environments. The 
official OMG name for common facilities is CORBAfacilities. 

• Application objects are the business objects that provide the application 
logic (for example, a payroll system). Although not yet standardized by OMG, 
application objects are critical when considering a comprehensive system 
architecture. Application object components represent those application 
objects performing particular tasks for a user. An application is typically 
built from a large number of basic objects — some specific to the application 
at hand and some built from a set of common facilities. 

3.2.3 OMG Object Model 

When any large body of contributors work together for a common technical good, 
it is necessary to work from a consistent basis of understanding and 
terminology. To this end the OMG Object Model defines common object 
semantics for specifying the externally visible characteristics of objects in a 
standard and implementation-independent way. The common semantics 
characterize objects that exist in an OMG-compliant system. 

The OMG Object Model is based on a few basic concepts: objects, operations, 
and types. An object can model any entity, such as a person, a boat, or a 
document. Operations are applied to objects and enable one to arrive at certain 
conclusions about an object, such as a person's date of birth. Operations 
associated with an object collectively characterize an object's behavior. 

Objects are created as instances of types. One can view a type as a template 
for object creation. An instance of type boat could be red boat, 38 feet long, with 
a seating capacity of 6. A type characterizes the behavior of its instances by 
describing the operations that can be applied to those objects. A relationship 
can exist between types. Example: a speedboat could be related to a generic 
form of boat. The relationships between types are known as supertypes and 
subtypes. 

The OMG Object Model defines a core set of requirements (based on the basic 
concepts of objects, operations, and types) in a Core Model, which be supported 
in any system that complies with the Object Model standard. While the Core 
Model serves as the common ground, the OMG Object Model also allows for 
extensions to the Core to enable even greater commonality within different 
technology domains. The concepts, known as Components and Profiles, are 
supported by the OMA and are discussed at length in the “Object Management 
Architecture Guide” available from OMG. 


3.3 Common Object Request Broker Architecture 

CORBA is the OMG's answer to the need for interoperability among the rapidly 
proliferating number of hardware and software products available today. Simply 
stated, CORBA enables applications to communicate with one another no matter 
where they are located or who has designed them. CORBA 1.1, introduced in 
1991, defined the IDL and the application programming interfaces (APIs) that 
enable Client/Server object interaction within a specific implementation of an 
ORB. 

IDL provides a standardized way of defining the interfaces to network objects. 
IDL is a strongly typed declarative language based on the C language syntax. 
Strong typing is essential for building large, robust, long-lived systems. The IDL 
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definition is the contract between the implementer of an object and the client. 

To support a given programming language, a mapping from IDL to the language 
is required. The CORBA 1.x specification defines such a mapping for the C 
language. However, work to provide further language mappings is in progress. 

The ORB is the middleware that establishes the client-server relationships 
between objects. Using an ORB, a client can transparently invoke a method on 
a server object, which can be on the same machine or across a network. The 
ORB intercepts the call and is responsible for finding an object that can 
implement the request, pass it the parameters, invoke its method, and return the 
results. The client does not have to be aware of where the object is located, its 
programming language, its operating system, or any other system aspects that 
are not part of an object's interface. The ORB provides interoperability between 
applications on different machines in heterogeneous distributed environments 
and seamlessly interconnects multiple object systems. 

In fielding typical Client/Server applications, developers use their own design or 
a recognized standard to define the protocol to be used between the devices. 
Protocol definition depends on the implementation language, network transport, 
and a dozen other factors. ORBs simplify this process. With an ORB, the 
protocol is defined through the application interfaces by means of the IDL. And 
ORBs provide flexibility. They let programmers choose the most appropriate 
operating system, execution environment, and even programming language to 
use for each component of a system under construction. More importantly, they 
allow the integration of existing components. In an ORB-based solution, 
developers simply model the legacy component, using the same IDL they use for 
creating new objects, and then write wrapper code that translates between the 
standardized bus and the legacy interfaces. 

CORBA is a signal step on the road to object-oriented standardization and 
interoperability. With CORBA, users gain access to information transparently, 
without having to know on which software or hardware platform it resides or 
where it is located on an enterprise's network. 

3.3.1 Structure of an Object Request Broker 

Figure 17 on page 28 shows the client and server components of an ORB. 
Communication between the client and server is accomplished through the ORB 
core , which is not defined by CORBA and is therefore implementation specific. 
Instead, CORBA defines some components built on top of the ORB core. The 
interfaces to these components are defined in the CORBA IDL and are therefore 
the same for all ORB implementations. 
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Figure 1 7. The Structure of a CORBA ORB 


The ORB client is responsible for the following activities: 

• Client IDL stubs define how clients invoke services on the servers. Services 
are declared using IDL, and client stubs are generated by the IDL compiler. 

• The dynamic invocation interface (Dll) APIs facilitate the discovery of classes 
and their function at run time. 

• The interface repository APIs enable the acquisition of descriptions of 
registered classes and the methods they support with their respective 
parameters. 

• The ORB interface consists of APIs to local services that may be of interest 
to an application. 

The server, also known as “object implementation,” is responsible for the 
following activities: 

• Server IDL stubs provide interfaces to each service exported by the server. 
They are generated by the IDL compiler, in much the same way as the client 
IDL stubs. 

• The object adapter interfaces with the ORB's core and accepts requests for 
service on behalf of the server's objects. 

• The implementation repository provides run-time directory information about 
the classes a server supports. 

As shown in Figure 18 on page 29, the ORB establishes the Client/Server 
relationship between objects. It intercepts the call from the client object and is 
responsible for: 

• Finding an object that can answer the call 

• Passing all parameters to the server object 

• Invoking its method 

• Returning the results to the client 

The ORB has to execute many functions to support this simple operation 
consistently and effectively, but the functions are hidden from the user. 
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Figure 18. The Client, the Server and the ORB. 


3.3.2 CORBA 2.0 Specification 

CORBA 2.0, adopted in December 1994, defines true interoperability by 
specifying how ORBs from different vendors can interoperate. The CORBA 2.0 
interoperability architecture, also known as Universal Networked Objects (UNO), 
specifies a simple, streamlined TCP/IP-based object messaging protocol. The 
OMG also allowed vendors to provide ORBs that support additional protocols to 
provide higher-function, distributed object services. This opens the door to IBM, 
HP, DEC, and others to build CORBA 2.0 ORBs based on the DCE protocols and 
services. 

Beside the interoperability issues, CORBA 2.0 clarifies some topics that were left 
open in the CORBA 1.2 specification. For example, the Interface Repository 
specification now defines the support for interface type equivalence checking, 
type codes, and IDL attributes. 

The specification is a merged version of two responses to the OMG ORB 2.0 
Interoperability and Initialization RFP. The first response to this RFP was 
submitted by BNR, Expersoft, IBM, ICL, IONA, and SunSoft. The interoperability of 
the first response was based on TCP/IP. A specification based on the DCE-CIOP 
protocol was submitted by DEC, HP, and IBM. OMG asked both groups to merge 
their specification and come back with a unified version. Therefore the final 
specification stands for a comprehensive, flexible approach to supporting 
networks of objects that are distributed across and managed by multiple, 
heterogeneous CORBA-compliant ORBs. 

The CORBA 2.0 specification currently defines the following components: 
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Component 

CORBA2/CORE 


CORBA2/lnteroperable 
CORBA2/C 
CORB A2/C + + 
CORBA2/Smalltalk 


Contents 

CORBA 1.2 

minus IDL C mapping 

plus extensions required to support some object 
services 

plus interface repository extensions 

plus ORB initialization 

plus inter-ORB bridge support 

CORBA2/CORE as defined above 

plus CORBA2/lnternet Inter-ORB Protocol (HOP) 

The IDL C language mapping, defined as a 

stand-alone specification 

The IDL C++ language mapping, defined as a 
stand-alone specification 

The IDL Smalltalk language mapping, defined as a 
stand-alone specification. 


Please note that each language mapping is defined as a single component. 


3. 3. 2.1 ORB Interoperability Architecture 

The ORB Interoperability Architecture provides a conceptual framework for 
connecting arbitrary ORBs. It describes bridging approaches both internal and 
external to ORBs. The architecture allows for flexible optimizations to ensure 
efficient bridging. It also covers several protocols, each allowing for a variety of 
lOPs. 


OMG document 93-9-15 defines interoperability as: “The ability for a client on 
ORB A to invoke an OMG IDL-defined operation on an object on ORB B, where 
ORB A and ORB B are independently developed.” 

The motivation factors for extending the current ORB architecture are numerous 
and vary with respect to scope, distance, and lifetime. Today, there are many 
different ORB products that address a variety of different user needs. Even when 
ORB implementations from a single vendor are used, there are reasons why 
some of the objects an application might use would be in one ORB, and others 
in another ORB. For example, there may be security reasons: even if the ORB 
implementation is the same, the ORBs would be separate, so that access to 
objects can be easily controlled. Supporting multiple ORBs also helps handle the 
difficult problem of testing and upgrading the object system. Just as networks 
are subdivided into domains to allow decentralized control of databases, 
configurations, and resources, the state of the ORB might also be managed by 
creating sub-ORBs. 

Interoperability with DCE: During the evolution of the CORBA 2.0 specification, 
the role that OSF's DCE played was not obvious. In fact many people considered 
the standards to be mutually exclusive. 

The OMG's decision to choose HOP as the mandatory protocol for any ORB to be 
CORBA2-compliant has been viewed by some as evidence that in the object 
world "DCE was a loser." The real story is that the DCE proposal did not die; it 
is an optional protocol that many vendors, including IBM will support. A case 
can be made that the OMG decision was a very prudent one, given the current 
state of distributed object computing in the marketplace. OMG chose the 
lightweight HOP protocol that can meet the needs of many departmental and 
small-scale, distributed object implementations, while at the same time providing 
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a solution for DCE users who require common object naming and security 
mechanisms across their enterprise. From a customer perspective this can only 
be a "Win, Win" strategy. The OMG did not turn its back on DCE as many would 
have you believe. DCE has a very strong place in the evolution of the world of 
distributed objects. 

OSF's DCE tackles a broad scope of issues associated with a complete 
distributed computing environment. DCE is a highly robust, scalable architecture 
that provides a comprehensive set of services, including distributed security, 
directory, and time services, as well as a programming and run-time 
environment based on RPCs. OMG's CORBA 2.0, however, tackles the important 
issue of how distributed object systems interoperate with one another in a 
network. CORBA 2.0 also defines an optional protocol mapped to the DCE RPC 
message formats. 

IBM recognizes that different customers have different computing needs. Some 
customers need a basic interoperability solution for small-scale, minimally 
configured systems typical of many current PC-based application environments. 
Other customers have a need for the industrial-strength security, reliability, 
scalability, and flexibility characteristics required for large-scale distributed 
environments. 

Domains: A domain enables partitioning of systems into collections of 
components that have some characteristics in common. The CORBA 2.0 
specification defines a domain as “a distinct scope, within which certain common 
characteristics are exhibited and common rules are observed: over which a 
distribution transparency is preserved." Interoperability, when crossing these 
domain boundaries, is a fundamental issue in the interoperability architecture 
design. 

CORBA distinguishes two different domains: 

Administrative Includes naming domains, trust groups, resource management 
domains, and other run-time characteristics of a system 

Technology Identifies common protocols, syntaxes, and similar build-time 
characteristics of a system. 

Examples of domains related to ORB interoperability issues are security 
domains, transaction domains, and referencing domains. 

Interoperability Bridges: Bridges, as defined in the CORBA 2.0 specification, 
enable requests from one ORB to be translated to requests on another ORB. 

To ensure the interoperability between domains, a well-defined mapping 
between the behaviors of the domains being joined is required. An ORB 
“provides the mechanisms by which objects transparently make and receive 
requests and responses. In doing so, the ORB provides interoperability between 
applications.” The interoperability of ORBs extends this definition by defining 
protocols allowing client and server objects located in different ORBs to 
“transparently make and receive requests. ” 

Figure 19 on page 32 shows the interoperability between different domains and 
possible different domain types. Note that every domain can use a different 
protocol. 
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Figure 19. CORBA 2.0 Interoperability Architecture 

The components of these bridges can be located in: 

In-line bridges The necessary translations and mappings are done 

inside the ORB 

Request level bridges The translations and mappings are done outside the 

ORB by application code. 

Request level bridges can be further distinguished: 

Half bridge The mediation is through a common protocol between distinct 

execution environments and is known as a half bridge. The protocol 
that is used can be a network protocol, shared memory, or some 
other inter process communication (IPC) mechanism provided by the 
host environment. 

Full bridge The mediation is purely internal to one execution environment and is 
known as full bridge. Full bridges are usually built by using a shared 
programming environment's binary interfaces to CORBA IDL-defined 
data types. 

3. 3. 2. 2 CORBA 2.0 Interoperability Protocols 

Figure 19 shows the protocols defined in the CORBA 2.0 specification. 
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Figure 20. CORBA 2.0 Interoperability Protocols 


The GIOP and the MOP are required for CORBA 2.0 interoperability. ESIOPs are 
additional protocols which can be added to a future CORBA specification. 
Currently, DCE-CIOP is the only protocol based on the ESIOP. 

We will explain all these protocols in the following sections. 

General Inter-ORB Protocol: The motivation for the GIOP was to define a 
simple-to-implement protocol with low run-time costs. This new protocol can be 
used by an ORB internally as well as when connecting different ORBs. The 
mapping from the GIOP can be done to any connection-oriented transport 
protocol. The GIOP makes only minimal assumptions about the architecture of 
the ORBs using it. A specific mapping of the GIOP, based on TCP/IP connections, 
is the HOP. MOP support is mandatory for every ORB product. This does not 
imply that the ORB has to use it internally, but that it at least provides a bridge 
to the protocol. 

The design of the GIOP is based on the following objectives: 

• Widest possible availability 

• Simplicity 

• Scalability 

• Low cost 

• Generality 

• Architectural neutrality 

Internet Inter-ORB Protocol: The HOP is a specific implementation of the GIOP 
and is required by a CORBA2-compliant ORB. The baseline transport specified 
for GIOP is TCP/IP. The HOP maps the GIOP message transfer specifically to 
TCP/IP connections. 

An Optional ESIOP — the DCE-CIOP: In addition to the GIOP and its specific 
implementation, the HOP, the CORBA 2 architecture includes additional 
environment-specific Inter-ORB protocols (ESIOPs). There can be many different 
implementations of this protocol, each optimized for particular environments, 
such as DCE. 


Chapter 3. Industry Standards 33 




The DCE-CIOP was designed with the following goals in mind: 

• Support of multivendor, mission-critical, enterprisewide, ORB-based 
applications 

• Leverage services provided by DCE wherever appropriate 

• Efficient and straightforward implementation using public DCE APIs 

• Preserve ORB implementation freedom 

The DCE CIOP uses the DCE RPC to provide message support. It is based on the 
wire format and RPC packet formats defined by DCE RPC to enable 
independently implemented ORBs to communicate. It also defines the message 
formats that are exchanged using DCE-RPC. DCE-CIOP requires an RPC that is 
interoperable with the DCE RPC. 

3. 3. 2. 3 CORBA 2.0 Smalltalk Mapping 

CORBA is independent of the programming language used to construct the 
implementation classes. However, to use the ORB, programmers must know how 
to access ORB functionality from the programming language of their choice. 
CORBA 2.0 defines the mapping of OMG IDL constructs to the programming 
languages, including C, C + + , and Smalltalk 

The following are highlights of the mapping of OMG IDL constructs to Smalltalk 
language: 

• The Smalltalk mapping has been designed with several vendors' Smalltalk 
implementations in mind, including: VisualAge, VisualWorks, and Smalltalk/V. 

• The Smalltalk constructs defined in the mapping rely primarily on classes 
and methods described in the ITSO redbook, Smalltalk Portability: A 
Common Base (GG24-3093). 

• Whenever possible, OMG IDL types map directly to existing, portable 
Smalltalk classes. 

• The Smalltalk mapping describes the public interface to Smalltalk classes 
and objects supporting IDL. It does not prescribe a specific implementation. 

For complete specifications of the CORBA 2.0 Smalltalk mapping, refer to 
OMG, The Common Object Request Broker: Architecture and Specification , 
Revision 2.0 (July 1995). 
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Chapter 4. The System Object Model 


IBM's System Object Model (SOM) is a software standard developed to ensure 
the portability of objects across platforms and development languages. It is an 
object packaging technology that is language-neutral, platform-independent, and 
supported by many third-party vendors. 


4.1 Problems with Today s Object Models 

Object-oriented programming is an important new programming technology that 
offers expanded opportunities for software reuse and extensibility. 
Object-oriented programming shifts the emphasis of software development away 
from functional decomposition and toward the recognition of units (called 
objects) that encapsulate both code and data. As a result, programs become 
easier to maintain and enhance. Object-oriented programs are typically more 
impervious to the “ripple effects” of subsequent design changes than their 
non-object-oriented counterparts. This, in turn, leads to improvements in 
programmer productivity. 

Despite its promise, penetration of object-oriented technology to major 
commercial software products has progressed slowly because of certain 
obstacles. This is particularly true of products that offer only a binary 
programming interface to their internal object classes (that is, products that do 
not allow access to source code). The first obstacle that developers must 
confront is the choice of an object-oriented programming language. 

So-called “pure” object-oriented languages (such as Smalltalk) presume a 
complete run-time environment (sometimes known as a virtual machine), 
because their semantics represent a major departure from traditional, 
procedure-oriented system architectures. As long as the developer works within 
the supplied environment, everything works smoothly and consistently. When 
the need arises to interact with foreign environments, however (for example, to 
make an external procedure call), the pure-object paradigm ends, and objects 
must be reduced to data structures for external manipulation. Unfortunately, 
data structures do not retain the advantages that objects offer with regard to 
encapsulation and code reuse. 

“Hybrid” languages such as C++ require less run-time support but sometimes 
result in tight bindings between programs that implement objects and their 
clients (the programs that use them). Implementation detail is often unavoidably 
compiled into the client programs. If there is tight binding between class 
libraries and their clients, client programs often must be recompiled whenever 
simple changes are made in the library. Furthermore, no binary standard exists 
for C++ objects, so the C++ class libraries produced by one C++ compiler 
cannot (in general) be used from C++ programs built with a different C++ 
compiler. 

The second obstacle developers of object-oriented software must confront is that 
software developed by using a particular language or toolkit is naturally limited 
in scope because different object-oriented languages and toolkits embrace 
incompatible models of what objects are and how they work. Classes 
implemented in one language cannot readily be used from another. A C + + 
programmer, for example, cannot easily use classes developed in Smalltalk, nor 
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can a Smalltalk programmer make effective use of C++ classes. 

Object-oriented language and toolkit boundaries become, in effect, barriers to 
interoperability. 

Ironically, no such barrier exists for ordinary procedure libraries. Software 
developers routinely construct procedure libraries that can be shared across a 
variety of languages, by adhering to standard linkage conventions. 
Object-oriented class libraries are inherently different in that no binary standards 
or conventions exist to derive a new class from an existing one, or even to 
invoke a method in a standard way. Procedure libraries also enjoy the benefit 
that their implementations can be freely changed without requiring client 
programs to be recompiled, unlike the situation for C++ class libraries. 

For developers who have to provide binary class libraries, these are serious 
obstacles. In an era of open systems and heterogeneous networking, a 
single-language solution is frequently not broad enough. Certainly, mandating a 
specific compiler from a specific vendor in order to use a class library might be 
grounds not to include the class library with an operating system or other 
general-purpose product. 


4.2 A Solution 

SOM is IBM's solution to the problems with today's object models. It provides 
an object-oriented programming technology for building, packaging, and 
manipulating binary class libraries. 

Figure 21 shows the positioning of SOM in an object-oriented environment. With 
SOM, class implementers describe the interface for a class of objects (for 
example, names of the methods it supports, return types, parameter types) in 
CORBA IDL. They then implement methods in their preferred programming 
language (which may be either an object-oriented programming language or a 
procedural language such as C). 
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Figure 21 . Positioning of SOM in an Object-Oriented Environment 
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4.2.1 Object Model 

The developers of SOM designed an advanced object model and implemented 
the object-oriented run-time engine necessary to support that model. SOM 
supports all of the concepts and mechanisms usually associated with 
object-oriented systems, including inheritance, encapsulation, and 
polymorphism. In addition, SOM provides a number of advanced object 
mechanisms including support for metaclasses, three types of method dispatch 
with both static and dynamic method resolution, dynamic class creation, and 
user intercept of method dispatch. 

SOM includes a run-time library, which provides a set of classes, methods, and 
procedures used to create objects and invoke methods on them. To use the SOM 
run-time library, a programming language must be able to: 

• Call external procedures 

• Store a pointer to a procedure and subsequently invoke that procedure 

• Map IDL types onto the programming language's native types. 

SOM classes are objects whose classes are called metaclasses. A class object 
differs from an ordinary object, because a class has (in its instance data) an 
instance method table defining the methods to which instances of the class 
respond. During the initialization of a class object, a method is invoked on it, 
informing the class of its parents. Thus the class can build an initial instance 
method table. Once the class object is initialized, other methods are invoked on 
the class to override inherited methods or to add new instance methods. 

When diagramming class hierarchies, we show metaclasses drawn with three 
concentric circles, ordinary classes (classes that are not metaclasses) drawn 
with two concentric circles, and ordinary objects (objects that are not classes) 
drawn with a single circle. Figure 22 on page 38 depicts the initial state of a 
sample SOM program and shows the classes of which the SOM run-time 
environment consists. 
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Figure 22. The SOM Run-Time Model 



Two relationships among objects must be understood. First, there is the 
instantiation or instance of relation between objects and classes, which is 
depicted by the dashed arrow line from an object to its class. When convenient, 
the inverse of instantiation, or class-of relation, is also used. In Figure 22, 
SOMObject is an instance of SOMCIass , and SOMCIass is the class of itself. An 
object's class is important because an object responds only to the methods that 
are supported by its class — the methods that the class introduces or inherits. 

Second, there is a inheritance relationship between classes called the 
subclass-of relation, which is depicted by the solid arrow line from a class to 
each of its parents. SOMCIass is a subclass of SOMObject. SOMObject has no 
parents. 

SOMObject introduces the methods to which all SOM objects respond. In 
particular, SOMObject introduces the somDispatch method, which provides a 
single general dynamic dispatch mechanism for executing method calls on 
objects. Furthermore, a class can arrange its instance method table so that all 
method calls are routed through somDispatch. As a result, it is simple for SOM 
metaclass programmers to arrange for completely arbitrary processing in 
connection with method invocations on SOM objects. 

As a subclass of SOMObject , SOMCIass is an object, but it also introduces the 
methods to which all classes respond. For example, SOMCIass introduces the 
somNew method, which creates instances of a class. Also, the methods 
responsible for creating and modifying instance method tables are introduced. 
All metaclasses in SOM are ultimately derived from SOMCIass. The SOM API 
allows new abstractions to be created by programming metaclasses. The 
strength of this general approach is that new abstractions can be created after 
the object model is implemented. The before/after metaclasses are not part of 
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the SOM kernel, but they are part of a framework for programming metaclasses 
that is built with the SOM API. By providing a metaobject protocol, we were able 
to add a new abstraction to SOM. 


4.2.2 Interface Definition Language 

SOMobjects Developer Toolkit Version 2.1 provides a SOM IDL compiler, which 
is key to language neutrality and supports the OMG standard IDL. IDL gives 
individual object implementations the means to tell potential clients which 
operations are available and how they should be invoked. By mapping the public 
and private types for a given SOM class to language-specific bindings, the 
compiler allows SOM objects to be used by different programming languages. 

Interfaces to SOM objects are described by means of IDL. SOM IDL is a 
CORBA-compliant version of IDL that allows SOM class descriptions to be 
supplied in addition to object interface definitions. (The interface to a class is 
described by the IDL alone. SOM IDL allows additional information about the 
implementation to be added.) The SOMobjects Developer Toolkit has tools called 
emitters that translate SOM IDL into language-specific bindings for the 
corresponding classes of SOM objects. For example, to C and C+ + 
programmers this means that emitters produce header files for both the users 
and the implementer of the class. 

The following example shows the basic structure of an IDL definition for an 
object interface called somAccount. 

Interface for somAccount 

interface somAccount : SOMObject { 

// method and attribute declarations here 

#i fdef SOMIDL 

implementation 

{ 

metaclass = SOMClass; 

// instance variable declarations here 

}; 

#endi f 

}; 


The above example is also a SOM IDL description of the somAccount class that 
supports the somAccount interface. The ttifdef and #endif parts of the IDL 
language are used to hide the SOM class implementation section from non-SOM 
IDL compilers. 

In the example, the somAccount interface inherits from the SOMObject interface, 
and at the same time, the somAccount class is declared to be a subclass of 
SOMObject. SOM supports multiple inheritance; additional parents of 
somAccount can be listed alongside SOMObject in a comma-separated list. The 
actual methods and instance variables of somAccount are not relevant to the 
current discussion. 

As illustrated, the implementation section can explicitly indicate a metaclass to 
be associated with the class of objects that supports the interface being defined. 
This association is not necessarily direct. The actual class of the class 
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described by any given SOM IDL is, in general, a subclass of the indicated 
metaclass. 

4.2.3 Language Independence 

One of the main advantages of SOM is the ability to describe the interface for a 
class of objects in a language-independent manner, namely within IDL. In 
addition to its programming interface to the SOM run-time classes, SOM 
provides language bindings as a more convenient way of using and 
implementing SOM classes. Language bindings tailor the SOM programming 
interface to a particular programming language. They make SOM classes 
appear like ordinary constructs of the programming language as much as 
possible. The methods of a SOM class can be implemented, for instance, in 
C++, whereas a client program using the class can be implemented in C. 

SOM can be used to provide object-oriented mechanisms for procedural 
languages (such as C or COBOL), or it can be used in conjunction with the 
capabilities of object-oriented programming languages like C++ or Smalltalk. 
In fact, several C + + vendors (including IBM) are currently incorporating SOM 
into their language run-time environment. SOM currently supports C and C + + 
implementation, with COBOL and Smalltalk implementation support available 
soon. 


Implementation 


C/C++ 

COBOL 

Pascal 

Smalltalk 

Other 



SOM Class Library 


Usage 

C/C++ 

► COBOL 
Pascal 
Smalltalk 
ObjectRexx\ 
Other 


Figure 23. Implementation and Usage Options Available with SOM 


Figure 23 illustrates the language independence of SOM libraries Objects can be 
implemented by using one language and used by a totally different language. 

Unlike the object models found in object-oriented programming languages, SOM 
is language-neutral. It preserves the key object-oriented programming 
characteristics of encapsulation, inheritance, and polymorphism, without 
requiring that the user of a SOM class and the implementer of a SOM class use 
the same programming language. SOM is said to be language-neutral for three 
reasons: 

• All SOM interactions consist of standard procedure calls. On systems that 
have standard linkage conventions for system calls, SOM interactions 
conform to those conventions. Thus, most programming languages that can 
make external procedure calls can use SOM. 

• The form of the SOM API can vary widely from language to language, as a 
benefit of the SOM bindings. Bindings are a set of macros and procedure 
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calls that make implementing and using SOM classes more convenient by 
tailoring the interface to a particular programming language. 

• SOM supports several mechanisms tor method resolution that can be readily 
mapped into the semantics of a wide range of object-oriented programming 
languages. Thus, SOM class libraries can be shared across object-oriented 
languages that have differing object models. A SOM object can potentially 
be accessed with three different forms of method resolution: 

- Offset resolution: roughly equivalent to the C + + “virtual function” 
concept. Offset resolution implies a static scheme for typing objects, 
with polymorphism based strictly on class derivation. It offers the best 
performance characteristics for SOM method resolution. Methods 
accessible through offset resolution are called static methods because 
they are considered a fixed aspect of an object's interface. 

- Name-lookup resolution: similar to the method resolution used by 
Objective-C and Smalltalk. Name-lookup resolution supports untyped 
(sometimes called dynamically typed) access to objects, with 
polymorphism based on the actual protocols that objects honor. 
Name-lookup resolution offers the opportunity to write code to 
manipulate objects with little or no awareness of the type or shape of the 
object when the code is compiled. 

- Dispatch-function resolution: a unique feature of SOM that permits 
method resolution based on arbitrary rules known only in the domain of 
the receiving object. Languages that require special entry or exit 
sequences or local objects that represent distributed object domains are 
good candidates for using dispatch-function resolution. This technique 
offers the highest degree of encapsulation for the implementation of an 
object, with some cost in performance. 

4.2.4 Release-to-Release Binary Compatibility 

SOM's release-to-release binary compatibility (RRBC) breaks the tight 
dependency between the code that implements a class and the client code that 
uses it. 

RRBC enables you to create and deploy a new version of a class without 
requiring that you recompile any unmodified application code. For example, you 
can add function or data members or even inherit from additional base classes. 
In general, if you make a change to a SOM class that does not require a source 
code change in a client, that client will not have to be recompiled. By packaging 
your class in a dynamic link library (DLL), you can replace the old DLL with the 
new one, and all the applications that used the old DLL will continue to run 
without modification. 

RRBC is a prerequisite for the subsequent modification of components (either 
applying fixes to or enhancing the components) without having to recompile 
preexisting clients that use them (upward binary compatibility). This is a key 
requirement because applications dependent on system libraries cannot be 
rebuilt each time a change is made to a component in the library. 
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4.2.5 Packaging Technology 

Objects built with SOM can be distributed and subclassed in binary form. Class 
library developers do not have to supply source code to enable users to 
subclass their objects. 

With SOM's RRBC, class libraries can be built that support robust binary 
interfaces. Client programs can be constructed that are derived from the 
classes in the library by using normal object-oriented inheritance techniques 
without compromising the ability of the class library implementer to make 
evolutionary changes in the library's internals, and without requiring all client 
programmers to use the same development language. In short, SOM objects are 
similar to the normal objects in an object-oriented programming language, 
except that their binary interfaces have been made more robust and replaced 
with language-neutral mechanisms. 


4.3 Relationship between CORBA and SOM 

How does SOM fit into the OMG CORBA picture? SOM is IBM's 
language-neutral implementation of the CORBA architecture. What does this 
mean? It means that SOM classes are defined by using the CORBA IDL; SOM 
supports all CORBA data types; the C language bindings for SOM classes are 
CORBA-compliant; and SOM provides an interface repository supporting the 
CORBA functionality and programming interfaces. 

SOM enables language-independent sharing of libraries, classes, and objects 
across existing host/client networks, as well as future Client/Server networks. 

With SOM, IBM is striving to achieve many of the same objectives as the OMG: 
To facilitate the interoperation of objects independent of their location, the 
programming language in which they are implemented, or the operating system 
or hardware architecture on which they run. 

4.3.1 Distributed Objects 

SOM's distribution component lets programs share object libraries across 
address spaces. Thus programmers can use a single programming interface to 
develop applications using both local and remote classes. For enterprisewide 
computing, this brings important flexibility to object-oriented programming, 
reuse, and sharing. The use and reuse of SOM objects depend on neither the 
original implementation language of the objects nor the location of the object on 
the network. 

SOM fully conforms with the OMG CORBA standards. In particular: 

• Interfaces to SOM classes are described in CORBA's Interface Definition 
Language (IDL) and the entire SOMobjects Toolkit supports all 
CORBA-defined data types. 

• The SOM bindings for the C language are compatible with the C bindings 
prescribed by CORBA. 

• All information about the interface to a SOM class is available at run time 
through a CORBA-defined “Interface Repository.”, The interface repository in 
SOM is a data store that contains all class information, method call 
definitions and user-defined data. 
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IBM's Distributed SOM will support both the DCE and UNO protocols in a future 
version. IBM will provide DCE-based directory and security services for both 
protocols to facilitate an even closer link between CORBA and DCE. 


4.4 IBM SOMobjects Developer Toolkit Version 2.1 

The SOMobjects Developer Toolkit includes a compiler that generates bindings 
for a given target language from the IDL description. Bindings are 
language-specific macros and procedures that allow a programmer to interact 
with SOM through a simplified syntax that is more natural for the particular 
language. For example, the C++ bindings enable SOM objects to be 
manipulated through C + + pointers to objects, using any C + + compiler. 
Direct-To-SOM support lets the programmer define and use SOM classes directly 
in C + + without needing IDL definitions. In addition to tools like the SOM 
compiler, for example, the SOMobjects Developer Toolkit Version 2.1 provides a 
set of object-oriented development frameworks. 

A framework is a set of objects that work together to perform a specific task. 
Graphical user interface frameworks, for example, allow objects such as 
windows, menus, and dialogs to work together to provide an efficient way of 
building consistent graphical applications. There are also frameworks for 
business problems, such as hospital management or inventory control. 
Well-designed frameworks provide the general design and implementation for 
specific purposes and enable a developer to customize them to suit a particular 
situation. 


Below we describe the various SOMobjects Developer Toolkit frameworks and 
then focus on the Distributed SOM Framework. 


Framework 
Distributed SOM 

Replication 

Persistence 

Event management 
Interface Repository 
Emitter 


Description 

The ability to access remote objects across address 
spaces and heterogeneous networks. Distributed 
SOM is a framework that implements a 
CORBA-compliant ORB 

A copy of an object can exist in multiple address 
spaces on a local machine or distributed over the 
network. The Replication Framework takes care of 
synchronizing updates on these copies. 

Saves and later restores object hierarchies from a 
persistent data store 

A central facility for registering all events of an 
application 

CORBA-compliant run-time access to all information 
in the IDL description of a class of objects 

Tools to write emitters 


Collection classes Organizes objects into base data structures such as 

queues, lists, and sequences. 
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4.4.1 Distributed SOM Framework 

The power of Distributed SOM (DSOM) lies in the fact that it insulates the object 
client from the object's location. With DSOM, application programs can access 
objects across address spaces, that is, in other processes, even on different 
machines. Both the location and implementation of an object are hidden from a 
client, and the client accesses the object (through method calls) in the same 
manner regardless of its location. 

DSOM can be characterized in two ways: 

• As an extension to SOM, enabling a program to invoke methods on SOM 
objects in other processes. 

• As an ORB, that is, a standardized “transport” for distributed object 
interaction. In this respect, DSOM complies with the CORBA specification 
published by the OMG and X/Open. 

Some of DSOM's more important features are: 

• Uses the standard SOM Compiler, Interface Repository, language bindings, 
and class libraries. DSOM provides a growth path for nondistributed SOM 
applications. 

• Enables an application program to access a mix of local and remote objects. 
The fact that an object is remote is transparent to the program. 

• Supports both interprocess communication in the same system and remote 
transport across systems. 

DSOM is extensible. Using a socket interface for communication services, it 
supports TCP/IP on AIX and TCP/IP, NetBIOS, and Netware on OS/2. In the 
future, it will support large-scale distributed environments, incorporating OSF 
DCE. 

4.4. 1.1 DSOM Workstation and DSOM Workgroup 

DSOM supports the distribution of objects among processes within a workstation 
(DSOM workstation) and across a LAN consisting of OS/2 and AIX systems 
(DSOM workgroup). 

DSOM workstation supports Client/Server object interactions among processes 
on the same machine, using existing interprocess communication facilities (IPCs; 
see Figure 24 on page 45). DSOM workstation, as a highly optimized, single 
address space ORB, provides interlanguage interoperability and supports binary 
subclassing and upward binary compatibility. 
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Figure 24. DSOM Workstation Environment 


The DSOM workgroup supports Client/Server object exchanges across networks 
of Windows, OS/2, and AIX machines. It uses socket-based TCP/IP, IPX/SPX, and 
NetBIOS stacks, and it can be customized to other stacks (see Figure 25). 



Figure 25. DSOM Workgroup Environment 
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4.4.1 .2 DSOM Servers 

In a DSOM environment client programs can access one or more distributed 
objects. These objects reside on DSOM servers. 

A DSOM server is a process that manages target objects on behalf of a client. It 
manages objects of a set of classes. In particular the DSOM server takes care of 
creation and destruction of instances of those classes. It handles messages 
passed to it from clients and passes them to the proper method of a target 
object. 

The classes supported by a DSOM server usually implement business logic, that 
is, they represent a part of the application's problem domain. They usually also 
have to access data held in databases or files. 

One or more class libraries provide the implementation of the classes the server 
has to manage. They are built as DLLs that can be loaded by the server on 
demand. 

A default server implementation (somdsrv) provided by DSOM can be used as a 
generic server program. The generic server simply receives request messages, 
executes them synchronously, and passes back the results to the client. 

The DSOM server must be registered with DSOM in the Implementation 
Repository before it can be used. A DSOM server does not necessarily have to 
run on a machine different from the client program; it can also run on the same 
system in a separate process. 

4. 4. 1.3 Simplified DSOM Environment 

Using the SOM objects in the FCE application as examples, Figure 26 on 
page 47 shows a high-level view of some of the components in a DSOM 
environment. Actually, more classes are involved in the DSOM environment 
than shown, but this simplified view provides a starting point for a basic 
understanding of DSOM. 
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Figure 26. Simplified DSOM Environment 


• DSOM Object Manager 

The DSOM Object Manager assists the client application with locating object 
servers. An object server, simply called a server in DSOM, is the program 
(process) running on the remote machine (or if DSOM workstation is used on 
the same machine in a different process). The server is the entry point into 
the application; it accepts requests on the objects that it controls. One could 
imagine the server to be a large program housing a large number of objects 
on behalf of many clients. The server waits within a request loop and 
executes requests on behalf of the various clients. It also provides high-level 
methods for creating and destroying remote objects. 

• Bank Server Proxy and SOMAccount Proxy 

A proxy is an object that is a local representative for a remote target object. 

A proxy inherits the target object's interface, so it responds to the same 
methods as the target object. 

The client contains proxies for real objects located in the server. The local 
client makes method calls on these proxies as if they were the target object. 
DSOM then passes the method call to the server where the method call is 
invoked on the actual objects, and the results are returned. 

Operations invoked on the proxy are not executed locally; they are 
forwarded to the real target object for execution. The DSOM run-time 
environment creates proxy objects automatically whenever an object is 
returned as the result of a remote operation. A client program always has a 
proxy for each remote object on which it operates. 

• Daemon 
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On any system that acts as a server, a separate daemon process called 
somdd.exe must be active. This process is instrumental in initializing server 
processes and creating the binding between the client process and the 
server process. 

• Bank Server Object 

In DSOM, the process that manages a target object is called the object's 
server. Servers are implemented as programs that use SOM classes. When 
a client asks for a server, it is given a proxy to a server object that provides 
interfaces for managing the objects in server. 

There is one server object per server process , which has the following 
responsibilities for managing objects in the server: 

- Provide an interface to client applications for basic object creation and 
destruction services, as well as any other application-specific object 
management services that may be required by clients. 

- Provide an interface to the SOM Object Adapter (SOMOA) for support in 
the creation and management of DSOM object references (which are 
used to identify an object in the server) and for dispatching requests. 

• SOMAccount Object 

The SOMAccount is another server object of an implementation class that 
uses SOM. 

• Implementation Repository 

A server's implementation definition must be registered in the 
Implementation Repository before a server can be used. The 
implementation definition contains server information that includes: 

- Name of the server program 

- Host name of the machine for the server 

- Classes that are associated with this server. 

When a client wants to use any of the somdFindServer. . . () methods, the 
DSOM Object Manager consults the Implementation Repository to find a 
server that can satisfy the request. 

The current implementation of the Implementation Repository consists of four 
flat files: 

• somdimpl.toc 

• somdimpl.dat 

• somdcls.toc 

• somdcls.dat 

DSOM looks for these files in the directory to which the OS/2 SOMDDIR 
environment variable points. 

Although not strictly required, the Implementation Repository files in most 
cases should be located on a shared file system to which all clients and 
servers have access. If the Implementation Repository is static, it may be 
possible to copy the appropriate files from one system to another and 
function without the shared file system. However, this is a dangerous 
practice and should be avoided in environments where the Implementation 
Repository is not static. The more dynamic the Implementation Repository, 
the higher the risk and cost of attempting to maintain multiple copies of 
identical files across systems. 

• Interface Repository 
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The Interface Repository provides a mechanism for storing interface 
definitions. Class interface definitions or signatures (a method's parameters 
and return value) are registered with the Interface Repository by compiling 
the IDL file with the ir emitter and the -u option that updates the interface 
repository. 

DSOM makes extensive use of information stored in the Interface Repository. 
Before an object can be accessed remotely by DSOM, it is necessary to 
register the class interface and implementation (from the IDL) in the Interface 
Repository. DSOM uses the interface information to drive the generic 
remote dispatch routine. Based on the parameter type descriptions in the 
interface definition, the remote dispatcher traverses the method call 
parameter list and copies the parameter data into a message buffer. A 
receiving process performs the symmetric operation when extracting 
parameter data from a message buffer. 

4.4.1 .4 DSOM Architecture 

Figure 27 illustrates the high-level architecture of DSOM. In the sections that 

follow we provide an overview of the functions on both the client and server side. 
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Figure 27. The CORBA-Compiiant DSOM Architecture 


Client Side 

DSOM dynamically creates a proxy object (and its proxy class) whenever a 
reference is made to a remote target object. 

Users of a remote object can syntactically pretend that they have a local object. 
Thus method calls can be written as if the object were local. 

By default, each proxy class is constructed to forward all method calls defined 
on the target class. This is accomplished by initializing the proxy class method 
table with pointers to SOM redispatch stubs, which are functions that convert 
specific method calls into calls to the generic dispatching method, somDispatch, 
and by overriding the somDispatch implementation to forward the method call 
(or request) to the remote object. Figure 28 on page 50 illustrates the dynamic 
creation of a proxy object during run time. 
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Creation of a 



Figure 28. Proxy Object Creation 


Server Side 

To activate an object, the object adapter consults the Implementation Repository 
which contains the information about the object implementation such as DLL 
name, process structure, etc. The Implementation Repository is a data store that 
is only needed by the server. In order to receive and dispatch each request, the 
object adapter must do the following: 

• Obtain the request message. 

• Demarshal the request. 

• Invoke the request locally (using the default somDispatch implementations). 

• Build a message to represent the response (marshaling). 

• Send the response message to the client. 

4.4.2 Replication Framework 

The Replication framework is a collection of SOM classes that enables a replica 
or copy of an object to exist in multiple address spaces while maintaining a 
single-copy image. In other words, an object can be replicated in several 
different processes while it logically behaves as a single copy. Updates to any 
copy are propagated immediately to all other copies. The Replication framework 
handles locking, synchronization, and update propagation and guarantees 
consistency among the replicas. 

The Replication framework can be exploited only if the applications are 
structured appropriately. The recommended structure is similar to the 
Model-View-Controller paradigm that Smalltalk programmers use. The 
Replication framework proposes a View-Data paradigm. The view object has no 
state but has methods to show a rendition of the state in the data object. In 
addition, it may have some data pertaining to the image that is displayed to the 
user. For example, in a visual presentation, the colors used for different regions 
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are in the view object, and the content information comes from the data object. 
The data object has whatever state information the application wants to store in 
it. 

The view and data objects must have a protocol between them so that when the 
data object changes, a signal is sent to the view object to note the change and 
refresh the display. This protocol can be extended to multiple views on the 
same data object, whereby an update to the data object is automatically seen in 
all visual presentations. Effectively, the views “observe” the data. 

The Replication framework is concerned with data objects only. Application 
developers must implement the “observation” protocol between the views and 
the data. The Replication framework requires that data objects be derived from 
a distinguished framework class, SOMRReplicbl. 

The Replication framework enables multiparty applications where the 
requirement is for each user to have access to his or her own copy of an object; 
that is, a single object with multiple shadows spread throughout the system or 
network. The framework provides all of the necessary functions for serializing 
the updates to the master object as well as selecting a new master if the original 
master unexpectedly goes away. 

Figure 29 illustrates the basic facts about the replication framework, which are 
as follows: 

• The Replication framework is the first implementation of replicas using 
objects. 

• The Replication framework synchronizes multiple copies of a single object in 
the address spaces of several distributed processes, thus providing the 
foundation for collaborative online activities such as: 

- Distributed whiteboards 

- Group editing 

- Games 

• Updates are communicated in real time, without the use of secondary store. 

• None of the participants knows how many replicas exist or where they are 
located, because replicas are totally transparent. In addition, any participant 
is free to join or leave the replica group at any time. 

• Replica support is made possible through multiple inheritance', all replicable 
classes must be derived from the SOMRReplicbl class. 



Figure 29. Replication Framework 
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4.4.3 Persistence Framework 

The Persistence framework is a series of classes enabling the state of an object 
to be easily stored and available after termination of the process that created it. 
This framework provides a generic interface so that the actual data store for the 
objects is independent of the method calls used to make an object persistent. 
SOM provides a default facility using the standard file system. However, one 
can easily extend this to use object-oriented databases or other facilities based 
on the application requirements. 

Figure 30 shows the basic facts about the persistence framework: 

• The persistence framework stores complex objects. 

• Objects contain persistent pointers to other objects. 

• The persistent store uses standard files. Objects can be grouped together in 
files or stored individually. Grouped objects are said to be near each other. 

Although the persistence framework uses a standard file system, persistent 
framework classes managing the store can be overridden to make them 
work with an object or SQL database. 

• Any IDL-supported data type can be declared persistent. 



Figure 30. Persistence Framework 
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4.4.4 Event Manager Framework 

The Event Manager framework, also known as EMan, is a central facility for 
registering all events of an application. This registration facilitates the grouping 
of various application events and waiting on multiple events in a single-event 
processing loop. The Replication framework and DSOM use EMan to wait on 
their respective events. Any interactive application that uses DSOM or 
replicated objects must also use the EMan framework. 

EMan handles the sending and receiving of asynchronous events. It is 
particularly useful in a single-threaded environment, where an application would 
like to be notified when a particular event occurs elsewhere in the system. 

Figure 31 on page 54 shows the structure of the EMan framework. 

EMan is similar in design to many typical graphical user interface (GUI) 
environments where applications have to respond to messages generated by 
external events or other components of the application: 

• EMan loops forever to handle events and distribute them to the callback 
methods. It is similar to the Presentation Manager (PM) event loop, except 
that events can be routed across the network. 

• EMan currently supports four event types: 

- Timer events 

- Sink events, such as socket calls 

- Client (for application-specific) events 

- Work procedure events, which are background tasks that can be 
executed when the event loop is idle. 

• EMan is extensible. Any special event can be managed by the application if 
the EMan classes are subclassed and personalized. 
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Figure 31. Event Management Framework 


4.4.5 Interface Repository Framework 

The Interface Repository framework is a database that consists of the 11 classes 
defined in the CORBA standard for accessing the Interface Repository. The 
Interface Repository framework provides run-time access to all information in the 
IDL description of a class of objects. 

Figure 32 on page 55 shows the inheritance hierarchy of the Interface 
Repository objects. 
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Figure 32. Inheritance Hierarchy of the Interface Repository Objects 


4.4.6 Emitter Framework 

The Emitter framework is a collection of SOM classes that allows programmers 
to customize the operation of the SOM compiler. The SOM compiler processes 
IDL files, which define class interfaces. The emitter framework simplifies the 
process of creating an emitter to generate language-specific bindings from an 
IDL file. 

SOM provides a set of emitters that generate the binding files for C and C++ 
programming (header files and implementation templates). Figure 33 on 
page 56 shows how the SOM compiler generates source files (such as C and 
C++ templates and the necessary language bindings) based on emitters 
defined by the user. In addition, developers can write their own special-purpose 
emitters. For example, an implementer could write an emitter to produce 
documentation files or binding files for programming languages other than C and 
C + + . 
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Figure 33. Emitter Framework 


As you can see in Figure 33 the emitter depends on some DLLs. Depending on 
the parameters by which the SOM compiler is called, a different emitter DLL is 
used. For example, if the SOM compiler is called with the following parameters: 

Invocation of the SOM compiler with the XH emitter 

sc -sxh somAccount.idl 


it uses the emitxh.dll to generate the somAccount.xh usage bindings. You can 
find the emitters that are part of the SOMobjects Developer Toolkit in the 
%sombase%\l ib\ directory. 


4.4.7 Collection Classes 

The SOMobjects Developer Toolkit provides a set of commonly required 
collection classes. These classes include: 


Hash table 
Dictionary 


Set 


A table of key and value pairs providing fast access by 
hashing on the key. 

A table of key and value pairs similar to the hash table. 
However, objects with equal keys can appear only once in the 
dictionary. 

An unordered collection of objects where the objects can 
appear only once. 
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Queue A list of objects where objects are inserted and removed in 

first-in-first-out (FIFO) order. 

Dequeue A double-ended queue; insertion and removal can occur at 

either end of the list. 


Stack A list of objects where objects are inserted and removed in 

last-in-first-out (LIFO) order. 

Linked list A list of objects where each object is linked to the object in 

front of it and behind it. 


Sorted sequence A collection of objects where the order is determined by how 
the objects relate to each other. 

Priority queue A special case of sorted sequence, where ordering is based 
on priority. 


Other collection classes designed to facilitate the use of the above classes. 


4.5 Outlook: SOMobjects Developer Toolkit Version 3.0 

Versions of SOMobjects have been available for years. As a matter of fact, SOM 
Version 1.0 was shipped with OS/2 2.0 in April 1992. Since then the SOM 
architecture has been improved in several areas. 

SOM Version 2.0 made a significant leap in terms of new features and new 
capabilities. It represented the first attempt of any commercial product to 
embrace the fledgling CORBA 1.1 standard. One major change was the move 
from IBM's Object Interface Definition Language (OIDL) to a version that fully 
complies with OMG's standard. Another change was to the infrastructure of 
SOM to support distribution through an ORB. 

The current version of the SOMobjects Developer Toolkit offers a powerful set of 
frameworks and IBM continues to extend this set with additional 
CORBA-compliant frameworks, that are based on the latest Object Services and 
Object Facilities specifications published by OMG. 

In the sections that follow we provide an overview of what you can expect of 
SOMobjects Developer Toolkit in the future. We cover some general ideas that 
will lead to a new implementation of SOMobjects. Our discussion is not, 
however, an announcement or a product plan. Nor do we claim to present a full 
list of features. 

4.5.1 Object Request Broker Interoperability 

Section 3.3.2, “CORBA 2.0 Specification” on page 29 describes the various 
CORBA 2.0 interoperability protocols. The HOP is mandatory for CORBA 2.0 
interoperability and will therefore be part of SOMobjects Developer Toolkit 
Version 3.0. However, we expect implementation of the DCE interoperability 
protocol for a future version of SOM. 
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4.5.2 Programming Model 

One of the design goals of the first version of SOM was support of 
release-to-release binary compatibility. This support will be maintained in all 
future versions of SOM. Thus the programming model will remain the same as 
in previous releases of SOMobjects. Nevertheless, SOMobjects will be 
restructured to provide maximum flexibility for enhancements so that porting 
teams and other vendors can extend SOMobjects as appropriate for their 
specific needs. 

DSOM interoperability between Version 2.1 and 3.0 is not supported, however. 
Because the use of the MOP for DSOM-to-DSOM as well as DSOM-to-other-ORB 
communications, the old wire protocol could not be supported. 

4.5. 2.1 Requirements 

To ensure portability and interoperability of objects developed on different 
hardware and software platforms, IBM supports the standards defined by OMG. 
To establish SOMobjects as a ubiquitous object middleware, SOMobjects must 
be available on all major 32-bit platforms. 

Because SOMobjects is used in totally different application areas, different 
implementations of SOMobjects must be provided. Large corporations, such as 
banks and insurance companies, have different needs regarding security, 
robustness, and performance compared to small software vendors implementing 
personal digital assistant (PDA) commmunication software. Implementations can 
share the same architecture and use the same APIs, but they differ in terms of 
their scalability and network protocol support. For example, one implementation 
supports only a few objects, and another supports millions of objects. Corporate 
customers using mainframe computers tend to use the SNA protocol, whereas 
customers working in a workstation environment tend to use TCP/IP. A specific 
implementation should work with all protocols but be optimized for a particular 
one. 

The management of systems is more challenging in a distributed environment 
than in a nondistributed environment. A distributed environment based on 
thousands of communicating objects must provide an infrastructure that enables 
multiple system management applications written by multiple, unrelated vendors 
to manage in a consistent way the objects created by an application 
programmer. 

4. 5. 2. 2 Local and Remote Transparency 

Applications developed by using SOM objects only locally do not have to 
reimplement those objects when moving to a distributed environment. This is 
one of the biggest advantages of SOM. Currently, only the client that creates 
and destroys a SOM object must be changed. In the future version of SOM, the 
way in which a client creates and destroys objects will be transparent for 
programmers. Therefore the APIs for local and remote object access will be 
almost the same. 

Remember that objects must be constructed with distribution in mind. There are 
significant performance penalties when a local object is moved to a distributed 
node. Typically, the local object inefficiently moves data to the application. 

When a distributed communications protocol is added, the application 
experiences tremendous performance degradations. 
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The better approach is to design all objects as if they will be distributed. The 
system administrator can then decide whether the objects are local or remote, 
without having to change the code that uses the objects. 

4. 5. 2. 3 Service Provider Interfaces and Customization 

Different users have different needs concerning performance, security, and 
robustness, among other requirements. Therefore customization for all possible 
combinations of uses is one of the most desirable features of a next-generation 
SOMobjects version. 

Implementing, testing, and supporting many customized versions is a costly 
undertaking, however. Based on the current requirements, we can think of three 
different levels of service provider interfaces (SPIs): 

• Porting SPIs: available only to porting teams that have full access to the 
SOMobjects source code 

• Value-added vendor SPIs: sophisticated SPIs available on only a limited 
basis to vendors for adding significant functions to SOMobjects 

• Customer SPIs: extensively tested SPIs available in the SOMobjects 
Developer Toolkit. Vendors can use them to tie in other products; customers 
can use them to customize installations. 

4. 5. 2. 4 Implementation Repository Redesign 

We can think of many requirements that should be considered for a redesign of 
the Implementation Repository. To enable the use of SOMobjects in a 
commercial distributed environment, the Implementation Repository must be 
able to hold information about a very large number of objects, without severe 
performance impacts. The Implementation Repository might be distributed 
across multiple administrative domains. Customization of the Implementation 
Repository is needed so that users can include domain- and application-specific 
information. The current Implementation Repository enables the use of a 
plain-file-based approach only. This approach might not be sufficient in all cases 
and raises the need for alternative storage mechanisms. 

4.5.2.5 Interface Repository 

Changes in DSOM marshalling have enabled type information to be moved from 
the interface repository to the class DLLs. Although support of information in the 
Interface Repository is supported for backward compatibility, we do not expect to 
see great performance improvements of the actual interface repository 
implementation. 

4.5.3 Object Services 

The current version of SOMobjects Developer Toolkit provides a comprehensive 
set of powerful object services. The next version will extend this set of object 
services to speed up application development and enable application 
programmers to concentrate on their specific application domain. 

4.5. 3.1 Persistence Service 

The OMG Persistence Service provides an architecture that supports two-level 
store (TLS) objects. The architecture has a router mechanism called the 
persistent object manager (POM), which finds the correct persistent data store 
(PDS) to drive the data store mechanism indicated by the object's persistent 
identifier (PID). The PID describes how to find the object's persistent data. The 
PDS is responsible for getting the data in and out of the object and into and out 
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of the data store. The PDS is the only entity that knows the data store's native 
interface. 

To enable objects to persist beyond the process that created the object, a 
persistence service is necessary. SOMobjects version 2.x offered such a service 
but was not CORBA-compliant. The next version will implement such a 
CORBA-compliant service based on the specifications of the OMG Persistence 
Service. With the support of persistent data stores, it will be possible to use the 
persistence service in a commercial environment. 

4.5. 3. 2 Naming Service 

The OMG Naming Service provides a standardized way of storing and retrieving 
object references by name. It provides the ability to bind a name to an object 
reference relative to a naming context. A naming context is an object that 
contains a set of name bindings in which each name is unique. 

Because naming contexts can be named in other naming contexts, the Naming 
Service supports hierarchical naming schemes for objects and naming contexts. 
Graphs of naming contexts can be supported in a federated fashion. 

The Naming Service part of SOMobjects Developer Toolkit Version 3.0 provides a 
light-weight implementation of the OMG Naming Service that deals primarily with 
name and object bindings. Not included in the OMG specification is the binding 
of properties and the possibility of performing searches. IBM will implement 
these features as well. 

4.5.3.3 Life Cycle Service 

The OMG Life Cycle Service establishes conventions for creating, deleting, 
copying, and moving objects. Because objects can be networked, the service 
accommodates life-cycle operations on objects in different locations. The client 
program's model of creation is defined in terms of factory objects. A factory is an 
object that creates another object. As with any object, factories have 
well-defined IDL interfaces. 

The Life Cycle service provides a light-weight, concrete implementation of the 
abstract OMG Object Life Cycle Service that also addresses the location 
transparency issues. The implementation is based on generalized factory objects 
that can be registered and searched in the Naming Service.lt is proposed that 
interfaces of these factory objects will be the object creation interfaces for all 
SOMobjects applications. 

4. 5. 3.4 Event Service 

The OMG Event Service defines push-style and pull-style delivery models. An 
Event fan-in (collect) and fan-out (multicast) model is also supported. 

The Event Service as part of SOMobjects Developer Toolkit Version 3.0 provides 
a light-weight implementation of the OMG Event Service based on DSOM as the 
event transport mechanism. It is possible that future versions will add other 
types of transport to provide more flexibility. 
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4. 5. 3. 5 Externalization Service 

The OMG Object Externalization Service is the OMG standard way of getting 
data into and out of an object. This service can be used, for example, to copy 
and/or move an object across address spaces or store and/or restore an 
object's persistent state. 

The implementation of the OMG Object Externalization Service is based on the 
IBM/SunSoft Object Externalization Service submission. (OMG is still working on 
a final specification.) 

4.5.3. 6 Security Service 

The upcoming OMG Security Service provides for secure operations of objects in 
a distributed system. 

Security is not only essential in a distributed environment; it is also far more 
challenging than in a nondistributed environment. Because the OMG Security 
Service has not reached its final state, IBM is implementing a first draft of the 
upcoming OMG specification. In the future, applications based on IBM's 
implementation might be changed in some areas when the OMG Security 
Service is standardized. 

In general, security covers several elements including authentication, 
authorization, audit, administration, and confidentiality. However, SOMobjects 
Developer Toolkit Version 3.0, will support authorization and authentication. 

4.5.3.7 Object Transaction Service 

The OMG Object Transaction Service provides the normal two-phase commit 
coordination. A user creates a new transaction context relative to the current 
context. If the current context is not null, a nested transaction will be started. 

Transaction monitors like CICS have a long tradition in IBM's history and are 
very important to customers. The Object Transaction Service as part of 
SOMobjects Developer Toolkit Version 3.0 provides transactional capabilities to 
distributed objects. In addition it also supports inclusion in the two-phase 
commit protocol of procedural resource managers that support the X/Open DTP 
protocol. Object transactions based on the OMG Transaction Service 
specification can therefore be mixed with procedural transactions. 

4.5.3.8 Concurrency Service 

The OMG Concurrency Service provides a lock manager that can get locks on 
behalf of either transactions or threads in the object's address space. When 
getting locks for transactions, it correctly handles lock inheritance for nested 
transactions. 

When speaking about the importance of transactions, the same is true for 
concurrency. Enterprise solutions depend heavily on the ability to process 
several tasks concurrently. For that reason the Object Concurrency Service 
allows easy implementation of locking protocols by application writers. 
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Chapter 5. IBM Distributed Smalltalk Technology 


IBM Distributed Smalltalk technology provides a set of Smalltalk classes and 
tools that are designed to support the development of distributed applications in 
an IBM VisualAge Smalltalk environment. The IBM Smalltalk language is 
powerful, easy-to-learn, and well suited to short development cycles. It lends 
itself to the development of GUIs as well as application business logic. IBM 
VisualAge for Smalltalk provides visual programming capabilities for the 
Smalltalk environment to further enhance programmer productivity. 

IBM's Distributed Smalltalk technology provides a two-level solution for 
distributed programming that is available for both the VisualAge for Smalltalk 
and IBM Smalltalk environment (see Figure 34): 

• Distributed Object Space, which takes advantage of “Smalltalk everywhere’’ 
applications to provide true local and remote transparency. Distributed 
object space technology is provided through the Distributed Feature 
available for both the IBM VisualAge for Smalltalk and IBM Smalltalk 
products. 

• Support for IBM's CORBA-compliant SOM and DSOM. This support is 
provided through the SOMsupport feature in VisualAge for Smalltalk and IBM 
Smalltalk as part of the base products. 



The Distributed feature extends the basic Smalltalk model to support distribution 
of objects in different object spaces. These objects can send standard Smalltalk 
messages to one another, regardless of their physical location. They can also 
freely send other Smalltalk objects as arguments and receive objects as results. 
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The different parts of an application can be located on any computer in the 
network that is running IBM Distributed Smalltalk. 

The VisualAge Smalltalk SOMsupport feature provides a mechanism for 
distributed programming in heterogeneous environments where some parts of 
an application are written in languages other than Smalltalk. The SOMsupport 
feature is intended for distributed applications that are built with multiple 
programming languages for which SOM bindings exist. Currently, this includes 
C, C + + , and IBM Smalltalk. 

IBM Distributed Smalltalk technology offers flexible development alternatives that 
ease the transition to object-oriented, distributed application development. 


5.1 VisualAge SOM/DSOM Support 

The VisualAge SOMsupport feature provides an interface through which 
VisualAge applications can use objects implemented with SOM. These SOM 
objects can be developed in any language that has SOM bindings. With this 
interface, VisualAge applications can create instances of SOM objects and send 
messages to them. This capability extends to the classes that make up the SOM 
kernel; VisualAge applications can interact with the SOM run-time environment. 

SOMsupport is implemented through the use of Smalltalk wrapper classes that 
represent SOM classes, as shown in Figure 35. 


Smalltalk SOM 



Figure 35. VisualAge SOMsupport Overview 

Interaction with these wrapper classes is the same as directly using the SOM 
classes they represent. When an instance of a wrapper class is created, an 
instance of the associated SOM class is also created. Interaction with the 
instance of the Smalltalk wrapper is the same as with any Smalltalk class. The 
attributes and methods of the SOM class are represented by methods of the 
Smalltalk class. 

SOM Smalltalk wrapper classes can also be used visually in the VisualAge 
Composition Editor. A wrapper object added to the Composition Editor appears 
as a nonvisual part. Attributes and actions on the part's public interface 
represent the attributes and methods of the SOM object. 
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5.1.1 New in VisualAge Version 3.0 SOMsupport 

VisualAge Version 3.0 SOMsupport includes a subset of the SOMobjects Base 
Toolkit, so no additional software is needed to create Smalltalk bindings in order 
to use SOM objects. The SOMsupport is delivered with complete pregenerated 
bindings for all SOMobjects base components to simplify setup. The 
SOMsupport provides both an API and a visual interface for creating SOM 
bindings. 

Enhancements in Version 3.0 include: 

• Conformance to OMG Smalltalk language mappings. This affects some of 
the SOM data representations in Smalltalk. 

• Improved exception handling. SOM exceptions are now mapped to Smalltalk 
exceptions, thus providing complete user control of exception handling with 
default behavior. 

• Support for SOM character output, such as somPrintf. Users can redirect 
SOM print output to a Smalltalk stream, such as the Transcript. 

• Support for all SOM data types, including float and pointer data types. 

• Improved data marshaling and demarshaling. Deep-nested, constructed data 
types are now supported. 

• Availability of all SOM global information in Smalltalk environment. 

• Automatic memory management for SOM parameters. Users do not have to 
do SOMFree. 

• Automatic environment management, removing the need for users to supply 
setup code. 

5.1.2 Expected Benefits 

By integrating the strengths of the VisualAge development environment with 
IBM's SOM and DSOM technology, VisualAge developers and end users of the 
resulting applications will benefit from the following enhancements: 

• Cross-language object classes 

Using currently available development tools, object classes developed in one 
language environment cannot be effectively reused in another language 
environment. 

SOMsupport enables VisualAge Smalltalk developers to reuse and subclass 
object classes developed in other languages. This possibility of 
cross-language reuse of classes significantly increases the availability of 
object classes in VisualAge and other development environments, such as C 
or C + + . In all, the support of SOM by VisualAge enables developers to 
reuse more code, thus resulting in less costly and risky development. 

• Support for CORBA distributed objects 

Client/Server computing is quickly becoming a normal requirement for the 
development and deployment of new applications. The OMG's CORBA 
standard (as fully implemented in IBM's SOM/DSOM technology) was 
designed to provide a productive, flexible, and dynamic Client/Server 
solution by exploiting the power of distributed object services. IBM's DSOM 
is a scalable extension of SOM that provides local and remote distributed 
object services across a heterogeneous network. 

VisualAge SOMsupport enables the development of CORBA-based 
distributed objects. VisualAge SOMsupport can significantly reduce the 
costs and risk associated with developing, deploying, and adapting 
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Client/Server applications while enhancing the migration path from local 
objects to distributed objects. 

• Support for SOM-based operating system services 

Over time, an increasing number of operating system services will be 
packaged as SOM object classes and frameworks. The first of these 
frameworks was the OS/2 Workplace Shell, which enables developers to 
customize, extend, and integrate into the Workplace Shell desktop as well as 
inherit behavior and characteristics (such as drag/drop) when developing 
new applications. OpenDoc, a compound document architecture supported 
by IBM, Apple, Novell, WordPerfect, and others, will be packaged as a 
framework of SOM classes that can be used in developing document-centric 
applications. 

VisualAge SOMsupport is positioned to exploit these frameworks, which will 
help automate the design and development of a new wave of 
document-centric, collaborative, distributed object applications. 

• Industry standard class definitions 

The SOM IDL and Interface Repository, which provides run-time access to 
class information and definitions, fully conform to the OMG's CORBA 
standard. 

The VisualAge Version 3.0 SOMsupport Smalltalk bindings are compliant 
with OMG standards as defined in CORBA 2.0 Smalltalk mapping 
specifications. VisualAge SOMsupport classes therefore will adhere to 
industry standards (CORBA IDL), enabling customers to retain investments in 
skills and code, while providing a mechanism for interoperability with other 
CORBA-compliant object ORBs (such as Hewlett-Packard's HP ORB). 

In summary, SOM, when integrated with the VisualAge development 
environment, can result in a more productive and powerful set of application 
development capabilities. 


5.2 VisualAge Distributed Feature 

VisualAge Distributed Feature provides Distributed Object Space support. When 
all parts of a distributed application are written in Smalltalk, IBM Distributed 
Smalltalk takes advantage of this situation with a technology called the 
Distributed Object Space. In effect, the Distributed Object Space extends the 
Smalltalk model across a network. 

IBM Smalltalk base. IBM's Distributed Smalltalk technology is based on IBM 
Smalltalk, an industrial-strength, object-oriented development environment. The 
industry-standard Smalltalk language provides a smooth transition to 
object-oriented development. IBM Smalltalk provides an open and extensible 
programming environment that supports large-scale team development with 
version control. 

IBM Smalltalk is the foundation of IBM's VisualAge, an object-oriented visual 
programming environment. IBM Smalltalk applications are portable to any 
platform on which IBM Smalltalk runs. With VisualAge and IBM Distributed 
Smalltalk, Smalltalk programmers can quickly begin to build portable distributed 
applications. 
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Smalltalk development model. Using IBM's Distributed Smalltalk technology, 
programmers can quickly develop applications that span networks, without 
having to learn the details of network communications, distributed application 
programming, or specialized interfaces. IBM Distributed Smalltalk extends the 
familiar Smalltalk tools — browsers, inspectors, debuggers, and workspaces — to 
the distributed environment. 

High-level development paradigm. IBM Distributed Smalltalk enables developers 
to focus on solving the business needs of the enterprise rather than on the 
mechanics of distributed programming. IBM Distributed Smalltalk is based 
entirely on the Smalltalk model, providing a very high level of programming 
abstraction and removing much of the complexity of distribution from the task of 
program design. 

Flexible distribution approach. The IBM Distributed Smalltalk model supports 
much more than a simple Client/Server approach. Applications can be “split” in 
many different ways, supporting both Client/Server and true peer-to-peer 
designs. The distribution of an application can be dynamically changed 
throughout the development cycle. 

Security. IBM Distributed Smalltalk uses the industry-standard Generic Security 
Service API (GSS-API) and currently supports Network Security Program (NetSP) 
Version 1.2. Used with NetSP, IBM Distributed Smalltalk provides transparent 
support for client authentication, message verification, and message encryption. 

True server programming. IBM Distributed Smalltalk provides full support for true 
server programming: 

• It is scalable to accommodate the demands of your business. 

• Its security support provides for authentication of clients and servers. 

• It supports concurrent execution of multiple client requests within a single 
server Smalltalk image. 

5.2.1 Distributed Object Space 

The Distributed Object Space is made up of multiple, individual object spaces. 

An object space is a single instance of a running Smalltalk image, and it can 
exist on any computer attached to a network and running IBM Distributed 
Smalltalk. With this technology, objects can: 

• Send standard Smalltalk messages to one another regardless of physical 
location. 

• Send and receive other Smalltalk objects as arguments and results — even 
across the network — without having to “flatten” them into serialized data. 

• Reside in different physical locations from one application version to the 
next, without requiring any change to the Smalltalk code. 

The Distributed Object Space enables developers to use the full power of the 
Smalltalk language, including high-performance messaging and efficient storage 
management through automatic garbage collection. 

Because the Distributed Object Space is based on Smalltalk, you can send 
Smalltalk objects as arguments to remote objects just as you would pass them 
locally, without any conversion necessary. The Smalltalk code used to send 
messages to remote objects is the same standard syntax used to communicate 
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with local objects. Therefore, at development time, the programmer need not be 
concerned with the physical location of the objects in the application. In fact, the 
physical location of the application modules can be dynamically changed 
throughout the development process, without any change to the Smalltalk code. 

5.2.2 Distributed Object Space Run-time Environment 

The Distributed Object Space run-time environment provides all of the support 
necessary to implement distributed execution of Smalltalk applications with true 
local and remote transparency. The run-time environment provides an 
additional layer on top of IBM Smalltalk (see Figure 36). It provides the 
following distribution services: 

• Messaging. IBM Distributed Smalltalk provides all of the communications 
logic necessary to send Smalltalk messages between object spaces. Once 
configured with the necessary location information, IBM Distributed Smalltalk 
handles the low-level task of passing Smalltalk objects across a network 
connection. 

• Distributed garbage collection. IBM Distributed Smalltalk extends Smalltalk 
garbage collection so that it is distribution-aware. Unused memory is freed 
when it is no longer being used by other local or remote objects. 

• Activation support. IBM Distributed Smalltalk provides the necessary support 
to start any remote Smalltalk images that are required by the application. If 
an object in one object space sends a message to an object space whose 
image is not currently running, the IBM Distributed Smalltalk activator 
automatically starts it. 

• Name server support. A name server is a directory of objects in a network. 

A name server contains object references, which provide information on the 
physical location of objects used by an application. By changing the object 
references, developers can update the location information for the objects 
without having to change the Smalltalk code. 

If the name server cannot resolve a particular object name, it has the ability 
to relay the request to a second-level name server. The IBM Distributed 
Smalltalk name server is designed to comply with the industry-standard 
OMG Naming Service specification. The name server is also designed to be 
adaptable to other naming services, such as the OSF DCE directory service. 
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Figure 36. Distributed Object Space Run-time Environment 
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5.2.3 Distribution Toolkit 

The IBM Distributed Smalltalk Distribution Toolkit is currently planned as a set of 
tools to help developers and administrators design, develop, debug, optimize, 
and configure distributed applications from a single physical location. The 
Distribution Toolkit will itself be set of applications that run on top of the 
Distributed Object Space run-time environment (see Figure 36 on page 68). The 
toolkit will include the following tools: 

• Remote Transcript and workspace windows. A remote Transcript window is a 
local window that mirrors the System Transcript window of a remote object 
space, enabling developers to interact with a remote Smalltalk image as if it 
were local. Likewise, a remote workspace is a standard Smalltalk 
workspace from which objects in a remote object space are addressable. 

• Remote inspectors and browsers. IBM Distributed Smalltalk extends the IBM 
Smalltalk inspectors and browsers to enable browsing and editing of remote 
objects and classes. Using these tools, you can browse other object spaces 
on the network; add, delete, and edit the classes that reside in those object 
spaces, provided you have authority to do so; and inspect and modify the 
contents of remote objects. 

• Distributed debugger. IBM Distributed Smalltalk provides an enhanced 
Smalltalk debugger that shows distributed program execution as a single call 
stack. The debugger enables you to trace program execution that spans a 
network just as you would with an entirely local application. You can also 
make changes to remote code from within the debugger. 

• Name server GUI. IBM Distributed Smalltalk provides a graphical user 
interface you can use to browse and update the contents of the name server. 
Thus you can add, delete, and change object references and other named 
objects. 

• Distribution configuration editor. This editor enables the developer to 
partition and distribute the modules of an application to the various object 
spaces on the network. Each module is a group of Smalltalk classes. 1 Using 
the distribution configuration editor, the developer can specify into which 
object spaces (images) each module should be loaded. After the location for 
each module is specified, the developer can also use this editor to 
automatically load the appropriate modules into the remote images. 

The distribution design of an application — the designation of which 
applications are loaded into which object spaces — is saved along with each 
version of the application. Developers can dynamically change the locations 
of the different modules of the distributed application to fine tune 
performance. 

The distribution design of an application is always kept in synchronization 
with any corresponding code changes. You can freely modify the design of 
the application to use a different distribution design without having to keep 
track of which versions of the code belong with each design. Each version's 
code and distribution are stored together. 

• Remote message probe. This tool profiles all messages traveling between 
object spaces. It shows you a stack containing every message sent from a 


f Each group of classes is actually called an application in the IBM Smalltalk Team environment, although in fact it may be only 
a part of your complete distributed business application. 
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particular object space. Thus you can analyze your message traffic and 
evaluate the efficiency of your design. 

• Event profiler. The event profiler enables you to analyze the message traffic 
among the objects in your application. Such analysis helps you decide the 
best way to split your application. For example, if two objects have a lot of 
traffic between them, they should probably be in the same object space, 
whereas two objects that seldom interact can generally be remote from one 
another. 

• Runtime configuration tool. This tool is used to set up the components of a 
distributed application on the system upon which it will run. When an 
administrator installs a distributed application, the runtime configuration tool 
ensures that the IBM Distributed Smalltalk runtime environment can find all 
of the object spaces and objects that make up the application. Using this 
tool, the administrator configures the name server information to reflect the 
physical locations of the object spaces that make up the application. 
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Chapter 6. Implementation Alternatives with SOMobjects 


This chapter describes the development environment in which a distributed 
object application based on SOM could be implemented. It describes the tool 
set needed for implementation and explains the implementation steps a 
programmer must follow to work with the SOMobjects Developer Toolkit to 
implement objects based on the IDL and the Direct-To-SOM approach. VisualAge 
Smalltalk provides some tools that enable easy access to SOM objects 
implemented with either approach. The implementation of the client part 
described in this chapter is based on the IBM VisualAge SOM support. 

C++ programmers can define SOM classes in one of two ways: through the 
CORBA standard IDL, or directly in C + + using a Direct-To-SOM C + + 
compiler. IDL is a language-neutral means for describing object interfaces, 
thereby enabling different compilers and even different programming languages 
to manipulate shared objects. The IDL definition describes the interface to, but 
not the implementation of, a SOM class. 

The server part of the application can be implemented using two different 
approaches. One approach centers around IDL as the main work product and 
uses the SOMobjects Developer Toolkit extensively. The other approach is 
based on the compiler supporting the Direct-To-SOM feature. Figure 37 shows 
the relationship between the two approaches. 



Figure 37. Direct-To-SOM and the IDL Implementation Approach 
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6.1 Interface Definition Language Approach 

Definitions 

The Free On-Line Dictionary of Computing on the World Wide Web defines 
server and client as follows: 

server: A program which provides some service to other client programs. The 
connection between client and server is normally by means of message 
passing , often over a network, and uses some protocol to encode the client's 
requests and the server's responses. 

client: A computer system or process that requests a service of another 
computer system or process. 


Distinguishing between these two terms is very important to an understanding of 
the development approach discussed below. 

Together with a C/C + + compiler like IBM's VisualAge for C + + , for example, 
the SOMobjects Developer Toolkit provides the necessary tools to develop SOM 
clients and servers. 

IDL, as opposed to languages like C, C++, and COBOL where you also 
implement your objects, was designed to describe the interface of your object. It 
is therefore only a declarative language; it has no syntax to describe the 
program logic. With SOM, class implementers describe the interface for a class 
of objects (names of the methods it supports, the return types, parameter types, 
and so forth) in CORBA IDL. They then implement methods in their preferred 
programming language (which may be either an object-oriented programming 
language or a procedural language such as C). 

Because the server and the client play completely different roles in the 
development process of a distributed object-oriented application, the 
implementation of a client and a server also differs. 

Steps to create a SOWI class library 

• Use the SOM IDL compiler to compile the interface definitions written in 
IDL. The SOM IDL compiler generates the following: 

- Object definitions in the Interface Repository 

- A skeleton for implementation 

- Language-specific implementation bindings (used by the implementer 
of the objects defined) 

• Build the implementation by starting from the skeleton 

• Compile and link the implementation, together with the implementation 
bindings, to generate the binary class libraries for the defined objects. A 
class import library is also generated for use by the users of the class 
library. 
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- Steps to use a SOM class library 

• Use the SOM IDL compiler to generate a language-specific usage binding 

• Write the client program with calls to the objects in the class library; 
consult the Interface Repository as needed 

• Compile and link the client program with the class import library and the 
usage bindings to generate the binary client program. 


An important aspect of the object-oriented paradigm is the idea of reuse. For 
that reason you probably want to focus more on the development of client 
programs than on the implementation of a server because you can reuse much 
more. In fact, we expect that the market for domain-specific class libraries, 
frameworks, or SOM-based components will rapidly grow within the next few 
years. This will give you the opportunity to buy the objects you otherwise would 
have to develop yourself. However, you probably want to build server programs 
that implement the specific flow of control of your business model. This should 
be the first step when building SOM class libraries. You should implement your 
business logic at least one time; afterward you can reuse it. Therefore we focus 
in the next section on the development of a SOM-based server. 

6.1.1 Server Development 

SOM server development consists of two steps. The first step is to develop the 
objects that will run in the server. These are usually the objects that implement 
the business logic and are therefore sometimes called “business objects.” To 
provide a run-time environment we also need an executable like a SOM server 
program. The general executable that is part of the SOMobjects Developer 
Toolkit can be used in most cases. 

For a detailed discussion of server development, refer to SOMobjects: A 
Practical Introduction to SOM and DSOM and the SOMobjects Developer Toolkit 
Version 2. 1 User's Guide. 

6.1 .1.1 DSOM Server Program 

A SOM class library is a class library packaged as an OS/2 DLL containing SOM 
objects. In a distributed environment, these objects will not run in the same 
address space in which the client program runs. We have to create a different 
address space. For that purpose, the SOMobjects Developer Toolkit includes a 
program called somdsvr.exe. This program is responsible for loading and 
activating objects from a library into memory. In most cases this server program 
provides everything you need. The SOMobjects Developer Toolkit 
documentation describes how to write your own server program. Writing your 
own program might be necessary if you need more control over the objects. For 
example, you could keep a list of objects in the server program that have been 
activated by the object. Because we use the generic server program that is part 
of the SOMobjects Developer Toolkit, we do not explain how to write a new 
server program here. 
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6. 1.1. 2 Developing a SOM Class Library 

The implementation of SOM objects packaged in a class library has two major 
advantages over the development process with traditional compiler technology 
like C++, for example. The implementation is language independent, so 
access to the library is possible not only from the language with which it is 
implemented but also from several other languages. In addition, the objects in 
the SOM class library can be distributed without changing their design or 
implementation. Although the implementation of the SOM class library is almost 
transparent with regard to local and remote access, in your design of a 
distributed application keep in mind the performance impact of accessing remote 
objects. 

Figure 38 highlights the steps in the IDL-based server implementation process. 
Note that the sequence of the steps is not the only sequence to use to build a 
SOM library. 



Figure 38. Class Library Development Based on SOMobjects Developer Toolkit 
1. Write the class descriptions in IDL. 

The design phase of a project results in an object-oriented design model that 
which describes in detail the classes, their attributes, and their methods. 

The object-oriented design model also documents class relationships such 
as inheritance, aggregation, and association. 

Starting with such a model, creation of IDL files really means mapping the 
details of the model to corresponding IDL constructs like attributes and 
methods. 
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2. Register the classes in the SOM Interface Repository. 

CORBA defines the concept of an Interface Repository and a set of methods 
to access it. As the name implies the repository contains interface 
information about classes that have been registered with it. Basically this 
information is equivalent to the information in an IDL file. At run time, an 
application can access the Interface Repository to gain information about a 
class needed to interact with the class or its objects. DSOM requires that 
objects that will be accessed from another process have their interfaces 
added to the Interface Repository. 

The SOM compiler is used to register a class given as an IDL file with the 
Interface Repository. 

Once the Interface Repository holds the class information and VisualAge is 
used for the client code, the client development process can start with 
deriving the wrapper classes from these SOM classes. 

3. Generate language bindings for C + + from IDL, using the SOM compiler. 

C++ language bindings are actually header files containing flat C++ class 
definitions. The bindings are required not only to make use of the SOM 
classes in client programs written in C + + but also to implement the SOM 
classes themselves to make them available by a server. 

Because the SOM compiler generates binding files, the programmer need 
not be aware of their specific contents and should not modify them. 

4. Generate C + + program skeleton code from IDL, using the SOM compiler. 

The SOM compiler produces a C++ source file, which contains everything 
that the class implementer needs, except the actual logic of the methods. 

The class implementer can now add the required logic. 

5. Add the logic of the class's member functions to the skeleton file. 

The class implementer modifies the generated skeleton file to add the actual 
logic to the method bodies that the SOM complier provides. 

6. Compile the completed class source file, using VisualAge for C + + . 

The C++ compiler is invoked in the usual way along with compiler options 
to ensure that it can find the SOM specific header files. 

7. Make SOM class implementation available as a class library. 

One of the principal advantages of SOM is that it makes binary reusability 
possible. This is why SOM classes are often packaged and distributed as 
class libraries. A class library holds the actual implementation of one or 
more classes. It can be dynamically loaded and unloaded as needed by 
applications. Furthermore, class libraries can also be replaced 
independently of the application that uses them. 

8. Register class implementation with the Implementation Repository. 

Before the application can be run, the server implementation must be 
registered with the DSOM Implementation Repository, so clients can find 
servers, and DSOM can activate those servers on demand. This installation 
must be effective on every machine that is going to use the SOM classes. 

9. Generate the stub DLL to run in the client. 
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6.1.2 Client Development 

Figure 39 on page 77 outlines the development process of a SOM client 
program. 

1. Generate usage language bindings from IDL 

The usage bindings for C++ supply functions for each method that uses the 
release order to map the method invocation to the appropriate slot in the 
method table for the class. 

Generate the usage bindings with the SOM included in the SOMobjects 
Developer Toolkit. The usage bindings define the public interface to a SOM 
class and are included by clients to create and manipulate objects of that 
class. Both the implementation and usage bindings files are regenerated 
completely by the SOM compiler when the class is modified, and they should 
not be modified directly. 

2. Write the main program 

With the C++ bindings, SOM objects are declared and manipulated as 
pointers to the given class. You use the new operator to create instances of 
a class. The first time an object of any class is created, the SOM run-time 
environment will implicitly be initialized. The first time an instance of a 
given class is created, the associated class object will be created, along with 
any parent class objects. The initialization of the SOM run-time environment 
includes the creation of a class object and the allocation of storage for an 
instance of the class, which can be assigned to a variable. Methods on SOM 
objects are invoked as on every C++ object. The final line of your main 
program should deallocate the storage for the object. 
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Figure 39. Client Development Process 


A difference between a program accessing local SOM objects and a program 
accessing remote SOM objects is the way objects are created and 
destroyed. DSOM uses its own proprietary APIs for that task. With 
SOMobjects Developer Toolkit Version 3.0 the OMG Lifecycle service will be 
supported, allowing the almost transparent creation and destruction of 
objects in a local and remote environment. 

3. Compile and link using VisualAge for C + + compiler 

This program can be compiled and run with any C + + compiler. The C + + 
compiler is invoked in the usual way along with compiler options to ensure 
that it can find the SOM-specific header files. 

4. Execute the client program 

The executable is invoked as every other executable on OS/2 is invoked. 
When you execute a client that accesses remote objects based on the DSOM 
framework, make sure that you have started the DSOM daemon, somdd.exe, 
on every server machine. Also make sure that the Implementation and 
Interface Repositories are up to date. 
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6.2 Direct-To-SOM Approach 

This section introduces the Direct-To-SOM approach to developing SOM objects 
and describes how it can be used with C++. Object-oriented language 
compilers that utilize SOM as their run-time library are referred to as 
Direct-To-SOM compilers. 

Figure 40 illustrates the fact that Direct-To-SOM users can compile C + + source 
code to create SOM-compatible binaries without having to write interface 
descriptions. The resulting objects can interoperate with SOM objects written in 
any other language. Moreover, the compiler can automatically generate IDL for 
C++ classes so that other SOM-supported languages that use IDL can interface 
with your classes. You can even subclass the OS/2 Workplace Shell just by 
writing C + + code. 



Figure 40. The Direct-To-SOM Implementation Approach 
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6.2.1 Relationship of Direct-To-SOM to Distributed SOM 

DSOM is a technology that handles creation and destruction of remote objects. 
Distributed object support provides for easier creation and reuse of SOM objects 
across platforms and operation systems that are SOM-aware. Combined with 
IBM's implementation of Direct-To-SOM C + + compilation, support for 
distributed objects is now greatly simplified and more practical for corporate 
application developers. 

The CORBA-compliant distribution of objects and the transparent access of those 
objects requires the support of IDL to populate the Interface Repository. 
VisualAge for C + + simplifies the creation of IDL greatly by generating the IDL 
from the interface description of the C++ class. Figure 41 illustrates the 
necessary steps in using this Direct-to-SOM development process. 



Figure 41. The Direct-To-SOM Development Process 


6.2.2 Relationship to C++ 

Experienced C + + programmers may find that the most surprising difference 
between SOM and the C++ object model is related to the role of object 
classes. In C++, a class is a syntactic entity that exists only at compile time; it 
has no representation outside the source code that defines it. A SOM class, 
however, is also a SOM object and always exists at run time. Because SOM 
classes are run-time objects, they can provide a number of services to client 
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objects at run-time. For example, each SOM class possesses a method named 
somSupportsMethod that, when invoked with any string, returns a value 
representing either true or false, depending on whether the class instances 
support a method whose name matches the parameter string. Other services 
supported by a SOM class include the following: 

• Reporting its name to clients 

• Identifying its base classes 

• Indicating whether or not a given SOM object is one of its instances 

• Reporting the size of its instances 

• Reporting the number of methods that its instances support. 

All interactions with SOM are through standard procedure calls. Because public 
instance data is not directly supported, any language that supports external calls 
can use SOM. However, SOM is most heavily used today with C and C++, 
mainly because of the support for generating bindings for these languages, and 
the Direct-To-SOM support provided by some C + + compilers. 

6.2.3 Direct-To-SOM C++ Compilers 

The capability to generate C++ bindings from an IDL description enables you 
to create and manipulate SOM objects with any C++ compiler, thereby gaining 
the advantages of the RRBC support provided by SOM. In addition, those objects 
can be shared across different C++ implementations or even with different 
languages such as Smalltalk. In using the C + + bindings, however, you are 
limited to a subset of the C++ language, which makes migration of existing 
C++ applications more difficult. You must also use two languages (IDL and 
C++) to define and manipulate objects. 

Direct-To-SOM (DTS) C++ compilers support and enforce both the C + + and 
the SOM object models, enabling C++ programmers to take advantage of SOM 
through C++ language syntax and semantics so that the use of SOM is 
reasonably transparent and efficient. Instead of first describing SOM classes in 
IDL, the DTS C + + compiler translates C + + syntax to SOM. You can then have 
the compiler generate IDL from your C + + declaration, or you may find that you 
do not need to deal with IDL at all and can work exclusively in DTS C++. 
Finally, because you write C++ directly, you can use C + + features in your 
SOM classes that were not available before DTS. These features include 
templates, operators, constructors with parameters, default parameters, static 
members, public instance data, and more. 

6.2.4 Direct-To-SOM Programming 

A C + + class is made into a DTS C + + class by inheriting from the class 
SOMObject , which is defined in the header file:som.hh. You can do this explicitly 
or implicitly through compiler switches or pragmas that insert SOMObject as a 
base class. The access specifiers-private, protected, and public-are supported 
for SOM classes and enforced following the C++ rules, as are constructors and 
destructors and most other C + + constructs. 

Once you have defined a DTS class, what can you do with it? You can create 
SOM objects statically or dynamically, as simple objects, arrays, or embedded 
members of other classes (or anywhere else that the declaration of a C++ 
object is valid). Most C++ rules and syntax apply to DTS classes and objects, 
with some restrictions. Because the size of a SOM object is not known until 
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run-time, compile-time constant expressions such as sizeof are treated as 
run-time constant expressions. Such operators can still be used with SOM 
objects, but not in contexts that require compile-time evaluation. 

A major inhibitor to RRBC with C++ is the fact that so much information about 
an object is statically compiled into client code-in particular, the location of 
instance data and virtual function pointers. Data layout and method calling for a 
DTS C++ class are performed using the SOM Application Programming 
Interface (API) instead of the native C++ API. When you run a program defining 
a DTS C++ class, the compiler will create the corresponding SOM class object 
at run-time and use it to create and manipulate the object. As a result, unlike a 
standard C++ object, much of the information about a SOM object and its 
class-such as the instance size-is not determined until run-time, when the class 
object is created. This enables class evolution without forcing recompilation of 
client applications. 

The SOM interface does not support direct client access to instance data. C++ 
instance data members in a DTS class are regrouped into contiguous chunks 
according to access, in the order of declaration within the class. This regrouping 
gives efficient access to data members from client code while enabling RRBC. 
The location of each chunk is determined at run-time. If the declaration order of 
public and protected data within a class is not changed, and new members are 
added after any preexisting members of the same access, this scheme allows 
new data members to be added without requiring recompilation of any code 
outside the class (except for friends). 

A DTS class also has a release order that, by default, will contain, in the order of 
declaration, all member functions and static data members introduced by the 
class, including those with private and protected access. In general, virtual 
functions that override virtual functions in a base class do not appear in this list, 
but will appear in the release order for the introducing class. Using the default, 
you must add any new member functions or static data members at the end of 
the class. Instead of relying on declaration order, you can use a pragma to 
specify the release order. In this case, you can add new release order elements 
anywhere in the class, but you must add their names to the end of the list. 

For DTS classes, instance data and the release order list are created at run-time 
by SOM and used to manipulate SOM objects, rather than the statically defined 
compiler constructs used by standard C++. This provides for both RRBC and 
an implementation-independent object model. As long as the order of list 
elements does not change and new elements are added to the end of the list, 
you can add new data members and member functions-including migrating a 
member function up the class hierarchy-without forcing recompilation of client 
code. 


6.3 Accessing SOM Objects Using VisualAge Smalltalk 

The VisualAge SOMsupport feature provides an interface through which 
VisualAge applications can use objects implemented using SOM. These SOM 
objects can be developed in any language that has SOM bindings. With this 
interface, VisualAge applications can create instances of SOM objects and send 
messages to them. This capability extends to the classes that make up the SOM 
kernel, meaning that VisualAge applications can interact with the SOM run-time 
environment. 
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SOMsupport is implemented through the use of Smalltalk wrapper classes that 
represent SOM classes. Interaction with these wrapper classes seems as 
though the programmer is directly using the SOM classes they represent. When 
an instance of a wrapper class is created, an instance of the associated SOM 
class is also created. Interacting with the instance of the Smalltalk wrapper is 
the same as with any Smalltalk class. The attributes and methods of the SOM 
class are represented by methods of the Smalltalk class. 

SOM Smalltalk wrapper classes can also be used visually in the Composition 
Editor. When adding a wrapper object to the Composition Editor, it appears as a 
non-visual part. Attributes and actions on the part's public interface represent 
the attributes and methods of the SOM object. 

6.3.1 Constructing VisualAge Wrapper Classes 

VisualAge SOMsupport includes a framework of Smalltalk classes called the 
SOM Smalltalk Constructor. These classes provide the ability to generate the 
Smalltalk wrapper classes that represent SOM classes, based on interface 
definitions that have been compiled from IDL files and stored in the SOM 
Interface Repository. Figure 42 shows the process of constructing certain 
wrapper classes from the Interface Repository. 



Figure 42. Creating Wrapper Classes from SOM Interface Repository 


Once the wrapper classes are generated, they can be used to interact with SOM 
classes. 
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6.3.2 Using Wrapper Classes 

Using VisualAge wrapper classes is very similar to using normal Smalltalk 
classes. The small differences are mainly in constructing and deleting 
instances of these classes. See "SC34-4518 VisualAge for Smalltalk: User's 
Guide", and the online reference book "VisualAge for Smalltalk: Features Class 
and Reference" for more details. 
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Part 2. Developing a Distributed Object Application 


Part 2 describes the development of a distributed object application. The 
application itself is a simplification of a real-world foreign currency exchange 
banking application. The initial object-oriented modeling of this application is 
described in the ITSO Redbook, Object-Oriented Application Development in a 
Client/Server Environment (GG24-4227). Part 2 refines the design of the foreign 
currency exchange application and extends it by using distributed objects, that 
is, an object-oriented implementation, for both the client and the server parts of 
the application. 


© Copyright IBM Corp. 1996 
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Chapter 7. The Foreign Currency Exchange (FCE) Case Study 


The Foreign Currency Exchange (FCE) case study project was first conducted at 
the ITSO San Jose Center during the winter of 1993. The project had the 
following goals: 

• Define a methodology to build real-life object-oriented applications with 
VisualAge. 

• Apply the proposed methodology to build an object-oriented banking 
application with VisualAge. The application was designed to run in a 
Client/Server computing environment. 

The results of the project were published in a redbook, Object-oriented 
Application Development with VisualAge in a Client/Server Environment 
(GG24-4227), which also introduced the Visual Modeling Technique (VMT), an 
object-oriented application development methodology that supports a visual 
programming environment like that provided by the VisualAge product. 

The FCE application has since then been ported to the latest version of 
VisualAge Smalltalk and VisualAge C++. It was also used to test drive a 
number of object-oriented analysis and design tools in a few ITSO residency 
projects. Please refer to “Related Publications” in the preface for more 
references. 


7.1 Requirement Specifications 

The bank (see Figure 43) has a number of worldwide branches. It provides its 
customers with various banking services, such as automated teller machines, 
credit card, and foreign currency exchange. 



© Copyright IBM Corp. 1996 
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The FCE application provides foreign currency exchange service. The service 
provides foreign cash and travelers check trading services to customers based 
on current exchange rates. Customers who have an account in a bank branch 
are considered bank customers. Customers who do not have an account in any 
bank branches are considered general customers. Both bank customers and 
general customers are eligible to use the exchange services. 

The FCE application provides the branch cashiers with country information, for 
example, country currency name, denominations of both cash and travelers 
checks, and foreign country currency restrictions. 

The cashiers get customer information, create an order, and receive an 
immediate response regarding the requested stock availability in their drawers 
and in the local branch. Customer orders can be pending, in process, or 
completed. Orders become pending only if sufficient stock is not available in the 
cashiers' drawer or in the local branch. 

The system manages foreign currencies, customers, orders and payments, and 
stock availability. 

Please refer to Appendix A, “Requirements Specifications” on page 155 for the 
complete requirement specifications of the sample application. 


7.2 The Solution Prototype 

The previous project team developed a VisualAge solution prototype for the 
application and ported it to VisualAge Smalltalk Version 3.0. The application 
prototype was developed by using VisualAge Smalltalk with remote data access 
to a DB2/2 database. 


7.3 Project Objectives 

Extending the work from the previous residency project, this project explored the 
distributed object perspectives in objected-oriented application development. 
More specifically, the focus was on applying the IBM VisualAge SOM/DSOM 
support in extending an application that involves distributed objects. 

In this project we extended a subset of the FCE application: the customer 
information management subsystem. Wherever possible, we try to reuse the 
analysis work result, and the same look-and-feel from the previous project. 


7.4 Project Iterations 

We went through a few iterations tor the extension case study, trying out 
different approaches that would illustrate how to develop distributed object 
applications with VMT and the implementing technology. 

We revisited the requirements study, the object-oriented analysis, and the 
object-oriented design of the original FCE case study before proceeding with the 
development of the application extension. 


88 Developing Distributed Object Applications 



7.4.1 Incremental Development 

This project also practiced building the application incrementally. We had an 
existing nondistributed FCE application and wanted to add new functions to it 
using distributed objects. For the object classes involved in distribution 
changes, that is, they are moved to a different object space and platform, we 
could expect a redesign of them. However, those parts of the existing 
application that were not distributed would remain very much the same with little 
or no change. The distributed portion of the application thus can be viewed as 
increments to the existing FCE. 2 

The VisualAge Distributed Feature provides distribution tool support for the 
design and development of distributed object applications. This support 
facilitated the incremental development. Applications can be developed as local 
(nondistributed) and then modified to suit a distributed object space environment 
(see Figure 44 and Figure 45 on page 90). 


Client Object Space 


fir- 

Client Server 


Figure 44. Incremental Development: Nondistributed 



Application 1 



2 During this project, we developed the customer management object server. Running concurrently, another residency project 
team developed the distributed currency management subsystem active server separately as a different subproject. The two 
projects used different technologies and can be viewed as two increments of the original application. 
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7.5 Distributed FCE Application Scenarios 

In Chapter 2, “Distributed Object Applications” on page 15, we introduce the 
concepts of object server , active server , and peer-to-peer , as the traditional data 
server takes on these new roles in a distributed object application environment. 
Let us look at how these new server roles are applicable to scenarios in the FCE 
application environment. 

7.5.1 Customer Management: Object Server 

Let us assume that the bank maintains customer and account information in 
centralized databases located in the bank center system. The branches are 
remote from the bank location. 

Bank-specific operations are carried out at the central site, that is, the bank. 
These operations may include certain customer management operations. 
However, the cashiers sitting in a branch also perform other customer 
management functions, such as: 

• Adding a new customer to the list of bank customers 

• Updating a customer's information 

• Removing a customer from the list of bank customers. 

The required information to perform these functions includes: 

• The list of customers and related customer information 

• The list of accounts and related account information 

• Certain information about the bank (such as bank name). 

Instead of accessing data from cashier client workstations using SQL database 
query, we can create objects in the bank server accessing databases locally and 
satisfy the client workstations for the required objects. Some reasons why this 
approach is desirable are: 

• Database access is required only on the server 

Client workstations do not have to issue queries to access remote 
databases. 
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• There are only a few objects (the customer and the account that reside in the 
server) that have direct access to the data, thus simplifying data 
maintenance at the central bank. 

• Network traffic can be reduced between the branch client workstations and 
the bank server. Thus the cashiers see a performance improvement of the 
overall FCE application. 

• The database software does not have to be installed in each client machine, 
so the software license cost could be reduced. 

The residency project described in this redbook focused on the development of a 
distributed customer management solution based on DSOM object servers. 

There are certain design considerations for distributed objects, which we discuss 
in Chapter 9, “Designing the FCE Application with Distributed Objects” on 
page 99. 

7.5.2 Exchange Rate Management: Active Server 

The bank center maintains the exchange rate for each currency centrally. 

In the previous project, we assumed that the exchange rates for all currencies 
were updated overnight and remained fixed during the day. The branch cashiers 
obtained the exchange rate for each currency to perform the foreign exchange 
transactions. 

In our project, to enable the cashiers to use a fluctuating exchange rate for 
currency trading, a list of all currencies with their corresponding exchange rates 
was located on a bank server (a center computer at the central site). All clients 
(the cashier workstations in the branches) had access to the currency 
information provided by the central site. 

The bank server containing the list of currencies was an active server in the 
sense that it informed all the interested clients when a change occurred. The 
clients could reflect that change on their corresponding views of the user 
interface. 

See Developing Distributed Object Application with VisualAge Smalltalk 
Distributed Feature (SG24-4521 -0) for more details on the development of the 
distributed currency management solution. 

7.5.3 Currency Trading between Banks: Peer-to-Peer 

By peer-to-peer we mean direct communication between two client machines. 3 
In the FCE application, a good example of peer-to-peer communication is the 
currency trading between two different banks. 

The bank center had to maintain the bank stock and trade with many other 
banks around the world. We assumed that there was an external system that 
offered the foreign currency trading facilities across a number of banks. Each 
bank would be required to pay a fee to use the system. The main requirements 
for this system were: 

• Maintain a list of all or most of the existing currencies and the rates each 
bank assigns to them. 


3 See 2.2.3, “Peer-to-Peer” on page 21. 
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This will help each bank to increase or decrease their own internal exchange 
rate. 

• Maintain a list of all trading requests that the member banks send to the 
system. 

A trading request specifies the available currency, the amount, the requested 
currency, the requested exchange rate, and the bank that originated the 
request. 

• Start direct negotiation between banks. 

After the initial setup, a connection can be established between a bank and 
the bank that originally sent in a trading request, without the intervention of 
the external system. In this way the banks can directly negotiate the rate, 
the bulk transportation, date, time, and additional considerations. 

We did not implement this peer-to-peer scenario in this project. 
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Chapter 8. Analyzing the FCE System 


In this chapter, we review the analysis work done previously for the 
non-distributed FCE case study application. We present the modeling result of 
the original FCE application and the modeling extensions required for the 
distributed FCE application (developed during this project). The extensions were 
mainly performed at the design level, because the primary goal of this project 
was to develop the FCE application with a distributed object architecture. 


8.1 Object-Oriented Analysis 

Analysis can be defined as the process of understanding and describing what is 
the problem to solve. Design is the process of deriving and describing how the 
solution will be implemented. Analysis is an important step, because it helps us 
to attack the right problem. Without proper analysis, we may build an elegant 
solution but end up solving the wrong problem. 

The analysis phase thus has two main objectives: understanding the problem 
domain and defining the desired application behavior. Understanding the 
problem domain requires that during the analysis phase the analyst, before 
starting any design and programming activities, gain enough knowledge of the 
characteristics of the environment and elements that are related to the problem 
the application is supposed to solve. The analyst should also have an 
understanding of the scope of the application as defined by user expectations. 

Defining (modeling) what the application is supposed to do (as opposed to how it 
should carry out the desired behavior) requires that design decisions concerning 
the implementation of the application solution should be made at a design 
phase. In fact, the analysis process and result can be independent of the target 
implementation environment. For this reason, most of the analysis results from 
the previous ITSO residency project were reused for this project. 

8.1.1 Studying Requirements for Our Case Study 

Basically the general requirements for this project were the same as those of 
the original FCE case study application (see Appendix A, “Requirements 
Specifications” on page 155). For easy reference, the assumptions made for the 
project are repeated here: 

• The branches are located remotely from the bank. 

• Now that the original FCE application is running in a branch, we should 
retain the same look-and-feel of the application to minimize the impact on 
the user. 

• The bank manages certain information centrally: 

- Customers and related customer information 

- Accounts and related account information 

- Certain information about the bank (for example, bank name) 

• Bank-specific operations should be carried out at the central site (that is, the 
bank). These include the customer management operations. Flowever, the 
cashiers in the branch should also be able to perform certain customer 
management operations, such as: 

- Adding a person to the list of bank customers 

- Updating a customer's information 

- Removing the customer from the list of bank customers 
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- Other than customer management, the branch handles all other 
branch-specific transactions, such as order management and branch 
stock management. 

• The bank currently retains the policy that each customer payment can only 
be made from one single account in the bank. 

In the process of understanding the requirements, it became clear that most of 
the analysis work from the original FCE case study can be reused, at least for 
the branch subsystem. 

The change of implementation technology and platforms for the bank server 
simply had no effect on our analysis of the branch. 

To save space and be friendly to the earth, we do not repeat the entire analysis 
here. For more information please refer to Object-oriented Application 
Development with VisualAge in a Client/Server Environment (GG24-4227). 

In the sections that follow we focus on object-oriented analysis related to the 
customer management functions. 


8.2 Reviewing the Existing Case Study 

This project began with a review of the requirements, work products from 
analysis and design, and the actual implementation of the existing FCE case 
study application. Like most projects, we had an existing application to deal 
with. We decided that making drastic changes to the existing application would 
not be the best way to "extend" it. However, the existing case study was 
developed using VMT, which covers all areas of business process modeling, 
analysis, and design, so we were able to harvest and reuse almost all of the 
work that had been produced previously. 

We were able to reuse some of the existing application code as well as the 
output from the analysis and design processes. This reuse drastically reduced 
the amount of work required to complete the new case study. 


8.2.1 Use Cases 

The use cases for the customer management function are repeated here for 
easy reference. Most use cases for other operations are reusable from the 
original FCE application. 

Customer Management 

• Create customer 

1. Cashier requests to perform customer management function 

2. System provides a form for the cashier to fill in 

3. Cashier completes the customer information form 

4. Cashier requests the system to perform the create job 

5. System performs the customer create job 

6. System notifies the cashier: job is successful or not 

• Update customer 

1. Cashier requests to perform customer management function 

2. System provides a list of customers to the cashier 

3. Cashier chooses the customer he or she wants to update 
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4. System informs cashier what customer he or she has selected 

5. Cashier requests to perform customer management function on the 
selected customer 

6. System provides a form to the cashier with customer information on it 

7. Cashier modifies the form with new information 

8. Cashier requests system to perform the update 

9. System performs the customer update job 

10. System notifies the cashier: job is successful or not 

Delete customer 

1. Cashier requests to perform customer management function 

2. System provides a list of customers to the cashier 

3. Cashier chooses the customer he or she wants to delete 

4. System informs cashier what customer he or she has selected 

5. Cashier tells the system that he or she wants to delete the selected 
customer 

6. system deletes the customer from the bank customer list 

7. system notifies the cashier: job is successful or not 
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8.2.2 User Interface 

We also reused the user interface from the previous project, as we wanted to 
retain the same look-and-feel for the application. Figure 46 shows the main view 
of the nondistributed FCE application, reused from the previous project. 



Figure 46. Main View of the Original FCE Application (Revised) 

Clicking on the Foreign Currency Exchange System push button opens the 
toolbar shown in Figure 47. The toolbar contains the push buttons for currency, 
stock, order, and customer management. It also has a pop-up menu, not shown 
here, that lets the user log on to the system. 



8.2.3 Object Model 

When analyzing the use cases, we decided to use the object model of the 
original case study as shown in Figure 48 on page 97. As the analysis process 
is the same for both cases, we do not repeat the discussion here. 
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Figure 48. The FCE Object Model with the Bank and Branch Subsystems 
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8.2.4 Dynamic Model 

Figure 49 shows the event trace diagram for the customer information update. It 
is based on the use cases for the customer management functions (see 8.2.1, 
“Use Cases” on page 94). We show only the update customer case here. 



Figure 49. Event Trace Diagram for Customer Information Update 


In summary, we reviewed the analysis work done previously for the 
nondistributed FCE case study application. Most of the analysis results of the 
original FCE application can be reused as we extend the application with a 
distributed object architecture. The extensions were performed mainly at the 
design level. 
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Chapter 9. Designing the FCE Application with Distributed Objects 


This chapter describes applying VMT in designing a distributed object 
application by extending the Foreign Currency Exchange (FCE) case study. 

Object-oriented design encompasses system design, object design, and object 
persistence design activities. System design focuses on the design decisions 
regarding the enabling and implementation hardware and software platforms. 

The system design work products are represented as system and application 
architecture and specifications. System design in a Client/Server environment is 
a complex topic and involves numerous design considerations. It is not our intent 
to cover all of these system design issues in this redbook. The focus is on 
designing for object distribution, including which objects are to be distributed 
and how they would be distributed. 

We followed the VMT design approach, which we summarize in the sections that 
follow. Object-oriented design is an iterative process. The design steps 
presented below in order are actually carried out iteratively. 


9.1 Designing Distributed Object Applications 

This section describes general considerations for and approaches to designing 
distributed object applications. If we are designing a brand new application, we 
must start thinking about object distribution from the very beginning of our 
application design. This approach should make it easier to change things during 
subsquent iterations. We still should start develop and test the nondistributed 
application locally first if at all possible. When we have verified that the overall 
logic of the nondistributed application works correctly, we can then distribute the 
application and start testing and tuning the distributed version. 

During the design of object distribution, several sources help to decide how to 
divide the classes for distribution: 

Requirement specification. The customer might have specified requirements that 
are related to the distribution of objects. 

Use cases. Which use cases will run in which types of workstations or 
platforms? 

Object model. Clusters of objects, that is, closely related objects with a high 
degree of interaction, should remain in the same object space to minimize the 
message traffic between object spaces . 4 Are there typical "server" objects, that 
is, common objects that are used by many different client workstations at the 
same time? 

Dynamic model. Are there interactions between similar kinds of objects within 
different machines (peer-to-peer requirements)? 

System design. Are there subsystems to be mapped only to certain object 
spaces? On which platform does the server system run? Are there LANs that 
run their own server? Objects can be distributed to platforms currently 
supported by VisualAge. 


4 In this book, we use the term object space in a generic sense to refer to a separate process or platform where the objects 
run. 
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Persistent object design. Where are the databases and data storage devices 
located? They should be on the same platform as the object servers if possible. 

The design activities of an object-oriented application can be categorized into 
three task groups: system design , object design , and object persistence design. 


9.2 System Design 

The outcome of system design is a high-level system architecture and application 
architecture for the proposed solution. These architectures define the major 
building blocks of the system (subsystems), the allocation of the subsystems to 
processes and platforms, and their high-level connectivity. 

During system design we must make initial decisions for the placement of the 
objects and the distribution of processes. We must take a closer look at the 
system environment in which the application will be running and consider: 

• Network related topics 

- What kind of network is or will be used? 

- What is the estimated traffic rate between the clients and servers? 

- Will the bandwidth of the network be able to handle this traffic load? 

• Geographical locations and their roles 

- How many different kinds of locations will there be for servers and 
clients? 

- Will there be several layers of servers (department, company, 
enterprise)? 

• Security, reliability, and usability topics 

- What are the security and reliability requirements for servers and 
clients? 

- Who has the right to use an object and how is the verification 
accomplished? 

- Which servers are responsible for maintaining persistent data? 

- What is the method of recovery after a system crash? 

Here we must also make a decision about which Client/Server enabling 
technology to use and for what purpose. For example, we can use the VisualAge 
Distributed Feature to distribute only some objects. Other objects will be local to 
the client object space or might use some other distribution technique, such as 
DSOM. 

9.2.1 Choosing the Implementing Technology 

VisualAge Smalltalk, with its SOMsupport and Distributed Feature, is a versatile 
power tool for developing the new breed of distributed object applications. 

In this section we list some criteria for choosing between the VisualAge 
Distributed Feature and SOM/DSOM support. The choice is not an easy one 
because the two features are based on quite different technologies and 
approaches. 

• Pure Smalltalk programming or language independence 

Which is good and which is not? We believe that this depends on the 
specific requirements of each customer. Some would prefer to develop an 
application with a single programming language; in this case Smalltalk 
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would be the better choice. Others would prefer to have classes written with 
language independence so that they can reuse the classes in different 
languages later on. SOM/DSOM will be more suitable under this 
circumstance. 

In some cases, the legacy systems that customers have may dictate the 
language they choose when they extend these systems. In other cases, 
there may be distinct advantages to choosing a particular language to use in 
the customer's environment. If a customer does not have these 
requirements, we believe that writing all of the code in plain Smalltalk is a 
much simpler and more straightforward way of developing object-oriented 
applications. 

Communication protocols 

Currently the VisualAge Distributed Feature supports only TCP/IP. However, 
DSOM supports TCP/IP, NetBIOS, and SPX/IPX. The support of protocol 
stacks in DSOM is extensible, so customers can even implement their own 
protocol stack if they choose to. 

Cross-platform requirements 

In the real world, most installations have more than one computer platform. 
Applications often have to be developed by using various languages, and 
they often run on different platforms. If we want to implement distributed 
cross-platform, cross-vendor applications, SOM/DSOM may be a good 
choice. 

SOM/DSOM is a proven technology for facilitating the communication of 
applications written in different languages. For example, a Smalltalk object 
application running on the client platform can communicate with C + + SOM 
objects running on the server machine. Currently, SOM and DSOM are 
supported in OS/2, AIX, Microsoft Windows, MVS, and other environments. 

Availability of frameworks 

SOM/DSOM provides a number of frameworks that are useful in developing 
distributed object applications. 

Release-to-release binary compatibility 

With SOM/DSOM, in a compilation language environment like C + + , client 
compilations are not required even though the server method 
implementations change. This eliminates the need to recompile most of the 
modules should one server method changed. Generally, if the changes to 
the SOM/DSOM objects do not require logic or source code changes in the 
client programs, those client programs will not have to be recompiled. 

Location transparency 

Location transparency means that the client application objects running on 
one platform do not have to know where the server objects actually reside. 
What client objects have to do is communicate with the server objects by 
sending messages in the same way regardless of whether the server objects 
are local or remote. 

Location transparency helps the distribution design for applications. 
VisualAge Distributed Feature and SOM/DSOM both provide certain level of 
location transparency support. Using either implementing feature, we can 
initially develop both the client application and the server application on the 
same machine. After we finished developing and testing the applications 
locally, we simply moved the server application to another machine. With a 
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few minor adjustments to communication and the DSOM settings, we had the 
client application communicating with the server application, without code 
changes in either application. 

• Flexibility, scalability, and extensibility 

If we have to make any changes to the implemented server environment, 
including moving it to another platform or rewriting it in another language, 
the client application would remain unchanged, provided that the interface 
between them is not changed. The reverse also applies. 

• Distributed tools 

The VisualAge Distributed Feature has many tools that help the developer 
build distributed applications. Tools like the distributed debugger and 
distributed event profiler help developers see which messages are going 
through the network and what is happening in the remote machine. None of 
these tools is available with the VisualAge SOMsupport. 

Instead, the SOM compiler provides a method-debug routine when it is 
generating the template functions. SOM class developers can use the 
method-debug routine for debugging how methods are invoked in a 
SOM/DSOM environment. Flowever, the debugging of the business logic still 
relies on the debugger of the language of choice. 

If we want to debug an application that uses SOM objects, we have to use 
the Smalltalk debugger for Smalltalk messages and the IBM Presentation 
Manager debugger (IPMD) for SOM messages. If we are using a DSOM 
object that exists in a remote machine, we have to use the IPMD in the other 
machine. As a result, the debugging is much more complicated with DSOM 
than with the VisualAge Distributed Feature. 

9.2.2 Subsystem Design and Placement 

This section describes some general considerations and criteria for the design 
and placement of subsystems. 

In general, subsystems must have clearly defined functions, be fairly 
independent, and have well-defined interfaces. When a cluster of classes adhere 
to the above criteria, they become candidates for subsystems. Subsystems are 
units for distribution because some of the considerations in selecting 
subsystems also apply to distribution. 

The placement of subsystems and some of their internal functioning are 
influenced by a number of business requirements, most importantly: data 
integrity, data consistency, performance, and availability. 

9.2.2. 1 Data Integrity 

Managing data remotely is not easy. This does not mean that distributed data 
cannot be managed without losing integrity. A number of feasible solutions exist, 
but exploring them here in depth is beyond the scope of this book. 

The designer must make the necessary trade-off between the level of data 
integrity dictated by the business requirement and the overhead and the 
associated performance impact costs. For example, even though the same level 
of integrity can be achieved with less overhead during run time, more time may 
be required to start up the application or recover from a system failure. 
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9. 2. 2. 2 Data Consistency 

Data consistency ensures that data values presented are true values. 

Consistency is not always needed, but if it is, several different schemes are 
possible, each with different consequences for the internal functioning and 
placement of subsystems. 

9. 2. 2. 3 Performance 

The placement of subsystems and the size and number of messages passing 
between them are the major determining factors in response time. 

9. 2. 2.4 Availability 

An application in which all subsystems are 100% dependent on the availability of 
all parts of the system works only when all subsystems are available. 

Subsystems can be designed to have few dependencies on other subsystems for 
most of their functions. Therefore, some functions of one subsystem can still be 
available in the case other subsystems are not available. 

During our system design with VMT, we began by decomposing the analysis 
object model into subsystems and mapped the resulting subsystems to separate 
VisualAge applications. This is a design strategy for the initial application 
architecture structure and development work assignment among developers. 

This division of the business application into a number of VisualAge applications 
enables a team of developers to proceed with development work concurrently. 

In partitioning the object model into subsystems, we might find some candidates 
for object distribution. But keep in mind that we should minimize object 
references that are across processes or network. We should divide only those 
subsystems into different object spaces that are loosely coupled and will not 
interact with each other very often. 

Figure 50 on page 104 shows the application architecture we used in our 
distributed FCE application. 
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Figure 50. Application Architecture for the Distributed FCE Application 


Figure 51 shows the system architecture we used in our distributed FCE 
application. 



Figure 51. System Architecture for the Extended FCE Application 


The relational database in the branch subsystem contains branch specific data, 
such as branch reserve, branch stock, and order information. 
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The relational database in the bank subsystem contains customer and account 
information. 

9.2.3 Function Placement (Fat Client or Fat Server?) 

Although we decided to separate the branch and bank subsystems, there were 
still some grey areas we had to consider. Where do we put the processing 
logic? Where do we put the data? The two questions are actually closely 
related. Let us look at the alternatives we have. 

• A fat client 

We can have a fat branch client that performs most of the processing for the 
whole system. We leave only the data storage and retrieval functions to be 
done by the bank server. 

• A fat server 

We can have a fat server that performs all processing logic, leaving only the 
user interface handling to be done on the client side. 

In the case of a fat client, as the server (in our case, the bank) does not filter any 
information it obtains before sending it to the client, there may be excessive and 
unnecessary traffic generated between the server and the client. The problem is 
even greater in a distributed object environment, because the attributes of an 
object may be another object (in an aggregate case), and that object's attributes 
can even contain other objects. 

Thus a "get attribute" message sent to an object will result in a number of 
database access requests to or from one or more tables. Performance, in this 
case, may be seriously affected. 

Figure 52 shows how a fat client can cause excessive data access loading in a 
distributed object environment. 
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In the case of a fat server, we have the client depending too much on the server. 
Again, we could have a performance problem due to the contention created by 
simultaneous access of the server from multiple clients. 

Our approach of functional division processing is somewhere in the middle of the 
fat client and the fat server cases. 

The branch function is carried out in the branch subsystem, and the bank 
function is carried out in the bank subsystem. 

We adopted the following design approach to avoid the problem of excessive 
database access to support the aggregation relationships between objects: The 
bank server, instead of performing a "deep" object data retrieval and then 
sending all actual data across the network, performs a "shallow" object data 
retrieval. For example, when handling a request for a list of customers, the bank 
server only returns a list of customers with their account IDs. The actual content 
of the account is not retrieved until the cashier requests it. This eliminates the 
potential performance problems and reduces network traffic loading. Figure 53 
shows our approach to maintaining a balanced system. 



9.2.4 Data Placement 

Refer to Chapter 1, “Distributed Systems” on page 3. for a general discussion 
of data placement. In our case we put the branch-specific data into the branch 
subsystem machine and the bank-specific data into the bank machine. 

We have one more thing to consider: should we cache information obtained from 
the bank into the branch itself? By caching some local data onto the client 
machine, we reduce the network traffic loading as well as the dependency of the 
client on the availability of the server. 

In our case study we kept a list of customer objects in the branch. This list was 
obtained by requesting customers from the bank object. However, this approach 
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raises one more issue: synchronization. What if there are a number of 
branches and each of them have cached local data (say, account information)? 
To simplify the case study we chose not to address the synchronization 
requirement. If we had chosen to address the synchronization requirement, we 
could have utilized the Replication framework provided with the SOMobjects 
Developer Toolkit. 

9.2.5 Other Considerations 

For simplicity, we chose to exclude security checks in both applications and use 
only the database security logon procedures supplied by OS/2. In the case 
study, all database update requests done on the customer, bank, and account 
objects are followed immediately by COMMIT statements, that is, for simplicity 
all requests during customer management are committed immediately. 

If we chose to implement a transaction-based operation during customer 
management, we could have used the rollback capability provided by the 
generated data access objects. The rollback method can return the database to 
its original state if a problem occurs. 


9.3 Object Design 

The primary goal of object design was to map the semantic classes identified in 
our analysis object model to solution domain classes (interface classes, 
application classes, and service classes). 

In our case study, the semantic classes became the required SOM/DSOM 
classes and VisualAge classes. During object design we repeated the following 
steps several times: 

• Refine object interactions and message flows of dynamic model 

- Evolve event traces with detailed message passing and additional object 
interactions 

- Prepare class specifications, methods and message formats 

• Design the details of the SOM/DSOM classes. Define and refine: 

- The public interface (attributes, actions, events) and methods 

- The instance methods and variables 

- The derived attribute policies 

From these as input sources, we produced the IDL files. 

• Review the design of the VisualAge visual classes for the application's GUI 
to consider whether we had to define or refine: 

- The elementary visual class for each application class 

- Additional composite visual classes as required 

- Input data validation 

- Deferred updates 

In our extension project, very little had to be done to the visual classes as 
we reused what we had from the previous project. 
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The object design phase involved the refinement and fleshing out of each 
object's internal structural and behavioral details, as well as details of object 
interactions. 


9.3.1 Designing the Solution Domain Classes 

The set of object classes that makes up a running application is usually much 
larger than the set of classes identified during the analysis phase. 

The initial set of semantic application classes identified in the analysis object 
model represents only the "core" business behavior of the application. 

Other solution domain classes must be designed to provide concrete 
functionality of the application. Interface classes that represent the user 
interface and "service" classes that provide service functionality such as input 
data validation and database access are some examples of additional classes 
required for the implementation of the application. 

The design of solution domain classes is, as in other processes of object 
oriented development, iterative. However, we suggest the following design steps: 

1. Map the semantic classes, identified in the object model from analysis, to 
application classes; this is almost straightforward. 

2. Add interface and "service" classes to provide user interface and additional 
functionality as required. 

9.3.2 Object Design for the Server 

As discussed in 9.2.3, “Function Placement (Fat Client or Fat Server?)” on 
page 105, we can have a simple server that handles only data access and 
retrieval. In fact, for our first cut of server design, we used this approach (see 
Figure 54). 



Note:The _gets and_sets to the attributes for SOM Bank, SOMCustomer, and SOMAccount 
perform direct access to the database. 

No logic was added and all codes are generated by the data access server 


Figure 54. First Cut of Server Design Object Model 
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In the second cut, we refined the design for better traceability and 
maintainability. Instead of directly accessing the database, we created a SOM 
class that used the data access objects to perform the data update and retrieval 
operations. We separated data access logic from business logic resulting in a 
more portable server. In addition, the SOM classes we created could have 
attribute names that related more to the business world than the database 
tables. For example, the customer object had an attribute of firstName instead 
of cust_fname. Figure 55. illustrates the object model for the refined design. 



Note: (1) The _gets and_sets to the attributes for SOMBank, SOMCustomer, and SOM Account use the 
corresponding data access server objects to access the database. 

(2) All attribute names are the same as those in the original FCE application. 

Therefore minimal changes were required for the client application. 


Figure 55. Second Cut of Server Design Object Model 


9.3.3 Object Design for the Client 

The client part of the application contains the user interface as well as the 
application logic and data management functions. In all cases, the user 
interface part adds some function to the model part of the application. 

Taking advantage of the SOM/DSOM support of VisualAge Smalltalk Version 3.0, 
we did not have to change much in the client. We could reuse most of the 
original design. 

To extend the application, we replaced the Bank class, Customer class, and 
Account class in the original FCE application object design model with the 
corresponding SOM wrapper classes (SOMBank, SOMCustomer, and 
SOMAccount). Thus, other objects, instead of interfacing with the original 
Customer class, now deal with the SOMCustomer wrapper class. No additional 
work has to be done, provided that the SOM wrapper class has the same public 
interface as the original object class, which it does. 

Figure 56 on page 110 and Figure 57 on page 110 show the "before" and "after" 
of the object model diagram. 
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Figure 56. Original Design Object Model with the Customer Class 
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Figure 57. New Design Object Model with the SOMCustomer Class 
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In fact, the only way other objects know that they are actually distributed across 
the network is by the different names we deliberately chose for the classes (that 
is, SOMCustomer instead of Customer; see Figure 58 on page 111 and Figure 59 
on page 1 12). 
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Figure 59. New CustomerQueryView after SOMCustomer Was Used 

We added a number of service classes for the SOM/DSOM support. As defined 
in CORBA, when the server object has a problem handling a request from a 
client object, it raises an exception. The exception travels all the way back to the 
client application, and the client program then takes appropriate actions to 
handle the exception. 

In our case study, for each SOM class we created, we defined an exception 
associated with it. In the branch machine, when we created a SOM wrapper 
class, we also created a SOM exception handling class to handle the exception 
coming back from the DSOM environment. 


9.4 Reuse Considerations 

Using an object-oriented language, we have three general ways of acquiring the 
services of other object classes, namely, through inheritance, aggregation, or 
delegation. 
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9.4.1 Inheritance 


Obtaining services through inheritance is quite straightforward. A subclass 
inherits all the attributes and operations defined in its superclasses. Thus all 
services of the superclasses are made available to the subclass as part of its 
public interface. The drawback of this approach is that the subclasses are very 
dependent on the superclasses, which can cause a lot of recompilation in 
languages like C++ or force developers to include the complete class 
hierarchy in languages with late binding like Smalltalk. 

9.4.2 Aggregation 

Services can be obtained through aggregation by creating a composite object 
class that contains the class with the desired services. In most object-oriented 
languages, the composite (aggregate) object usually contains a reference (object 
ID) to the contained object rather than the object itself. The composite object 
and the contained object are coupled with this aggregation relationship. 

However, the coupling is not as tight as the inheritance relationship. 

Providing the services to the client through aggregation enables one to define a 
cleaner interface between the server and the client. 

Creating an Interface class using aggregation at the server provides even more 
flexibility. It can hide all function that is not needed. It lessens the dependency 
on a superclass, therefore causing fewer recompiles, and does not force a lot of 
classes to be present during run time for languages with late binding. The 
drawback is that all methods that are part of the interface have to be coded in 
the composite class. 


9.4.3 Delegation 

Services can be obtained through delegation by invoking the desired service of 
another class — by sending it the proper message. A class can invoke the service 
of any classes with which it has an association relationship. Delegation is the 
most flexible way in which classes can collaborate with each other with 
minimum coupling. 

9.4.4 Effects of Inheritance and Aggregation 

Figure 60 on page 114 through Figure 63 on page 117 illustrate the effects of 
inheritance and aggregation. Note that the effects of inheritance differ when the 
client is implemented with a programming language with static binding, such as 
C+ + , or with late binding, such as Smalltalk. Another point to note is that, 
using inheritance, we can subclass a server class written in C + + in a Smalltalk 
environment. This is made possible by SOM. 

Figure 60 on page 114 shows the use of inheritance to add a method to the 
class behavior with a static binding programming language. 
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In the figures, we have two server classes, A and B, where class B is a subclass 
of class A. On the client side we have class C, which adds the method c. 

The donuts represent the classes, and the methods of the classes are 
represented with a single letter. The bold letter is the method implemented for 
that class. The italic letter is an inherited method. An underscored letter is a 
method needed on the client side. 

Figure 60 shows a superclass A having a method a with a subclass B having a 
method b. Both methods are available on the client side, and the subclass C of 
this DSOM class adds the c method. 

Figure 61 on page 115 shows the same construction, but now with a late binding 
programming language. 
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Because the binding is done at run time, all classes in the inheritance hierarchy 
tree in the server must be present on the client side as well. When the client is 
implemented with VisualAge Smalltalk, we have to generate wrapper classes for 
both A and B, which causes more work during development and has negative 
effects on performance during run time. This may not sound too dramatic, but 
the impact becomes clear in 10.2.1, “Generating VisualAge SOM Wrapper 
Classes for the Client” on page 139. 

Figure 62 on page 116 illustrates late binding with aggregation on the client 
side. 
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Figure 62. Late Binding with Aggregation on Client Side 


With this option only the desired behavior of the class defined in the server is 
enabled. It requires fewer recompiles but has the same overhead on the client 
side as late binding with inheritance (Figure 61 on page 115). It also provides 
more flexibility in creating instances and facilitates the coding to populate object 
structures as described in 10.4.1, “Support of SOM Data Types” on page 144. 

Figure 63 on page 117 depicts late binding with aggregation on both the server 
and the client. 
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This is the best solution when the client side uses a language with late binding, 
such as VisualAge Smalltalk. It eliminates the need for a repeated inheritance 
structure on the client side, with all of the associated problems as discussed in 
10.2, “Client Implementation” on page 138. It also is the best solution for 
maintaining project library control in a project that uses different platforms. 

9.4.5 Effects of Extending the SOM Wrapper Classes 

This section examines the effects of directly extending the generated SOM 
wrapper classes in the VisualAge Smalltalk environment (see Figure 64 on 
page 118). We explored this approach in our case study. From the client 
application point of view, it only cares about the services that a customer class 
provides, it does not matter how the customer class is actually implemented. 
Whether the customer class is a SOM-enabled class or a native Smalltalk class 
should not affect the client application. Thus, any customer-specific methods or 
attributes could be added to the customer class. 

If a SOM wrapping process is to occur in the future, the SOM wrapper in 
VisualAge will make only those modifications that are required. All methods, 
whether they were added in the Smalltalk environment or obtained from the 
previous SOM wrapping process, are left untouched if they do not require 
changes. 

Although directly extending SOM wrapper classes is possible, it should be done 
with caution and only in certain cases because the approach has some negative 
implications. For example, if you add instance data to a wrapper class, the 
instance data cannot be made persistent through SOM. Also, by directly 
extending SOM wrapper classes, we broke the explicit contract between the 
client and the server as represented by the IDL description of the server 
interface. 

If you are adding real functions as opposed to minor auxiliary functions to assist 
in the Smalltalk environment, do not directly extend SOM wrapper classes. 
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9.5 Object Persistence Design 

Design trade-offs have to be considered in the following two cases when 
designing a distributed solution: 

1. Objects in server object spaces with local access to the database 

Obviously the corresponding persistence manager class should reside in the 
same object space. 

2. Objects in server object spaces without local access to the database 
Three different approaches are available, each with its own pros and cons: 

• Put the corresponding persistence manager class in the object space 
that has local access to the database. Use a shadow of the persistence 
manager to access its services. With this approach, object and data 
access are combined within the same object space, but the complete 
object will be transferred between the object spaces over the network. 
Because the persistence manager uses instance methods to populate 
the object's data, the object class has to reside in that object space too. 

• Put the corresponding persistence manager class in the same server 
object space and use remote database access. With this approach, the 
object class and its persistence manager class will reside in the same 
object space, but the SQL query and results will be transferred over 
network. 

• Move the object class and the persistence manager into the object space 
that has local access to the database to minimize the SQL traffic. Use a 
shadow to access the object. With this approach, the object class and its 
persistence manager class will reside in the same object space with 
local SQL traffic, but every message to the object instances, and the 
message's return value, will be transferred over the network. 

When designing with SOM/DSOM, we could consider using the SOM Persistence 
Object Service (POS). 
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9.5.1 SOM Support for Persistence 

The OMG has adopted a specification for POS that provides an industry standard 
for writing data store independent code and for plugging existing data stores into 
an object storage framework. The adoption of the POS standard by the OMG will 
likely have a major impact on the way object-oriented storage systems are 
designed and used in the next few years. 

POS is based on the architecture of the Persistence framework in SOM Release 
2.0, with significant changes to better support the plug-and-play philosophy. In 
the next release of SOM, the Persistence framework will be updated to follow 
this specification. 

The POS specification provides important benefits. It ensures that the same 
client code can be used for storing objects regardless of whether the object is 
stored in file systems, relational databases, object-oriented databases, or other 
data stores. For the first time, programmers have a well-defined interface for 
storing objects in existing corporate-centric data stores, such as relational 
databases. 

The POS standard also defines the components that must be implemented by 
data store vendors to support the storage of objects. IBM is currently working 
on POS plug-in components for DB2, IMS, stream files, and other data stores so 
that traditional IBM data stores, such as DB2 and IMS, can be used as 
full-fledged storage facilities for objects. 

There are many advantages to using traditional data store products as object 
data stores, for both developers and application consumers. Developers will 
have an industry-defined standard for accessing existing corporate-centric data 
and storing object data in a format compatible with existing multimillion dollar 
software investments. Application consumers will be able to exploit mature data 
store technologies to ensure the reliability and integrity of their data. 

The POS standard is designed to support object-oriented databases as well as 
traditional data store products. This support offers application developers the 
best of all worlds: a single-object interface to a multitude of data store products 
that encompass the best of the past, present, and future. 

9.5.2 Object to Database Mapping 

Object persistence design focuses on how the data for persistent objects should 
be stored and retrieved in the target system. In our case study, we examined 
these design tasks: 

• Model and design server databases 

• Define the interactions between database objects and model objects 

• Define the distribution of objects in user images 

• Define access policies for retrieve update shared data. 

However, we did not have to significantly modify the original design. 

Below we describe the approach we took to store objects in DB2, namely, object 
to database mapping. Although not a complete solution to the task of storing 
objects in a relational database, it is an extensible approach. 

1. Each class maps to one (or more) tables. For ease of maintenance the tables 
are given the same names as the classes from which they were derived. 
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2. Each base attribute (char, int,...) of a class maps to one column in the table. 

In the case where an object attribute type is not supported by the database, 
the database supported type is used in the class. 

3. Each object maps to one row in the table. 

4. Each attribute of type object or collection of objects is mapped as follows: 

•1:1 relationship (1 company, 1 address) 

In a 1:1 relationship a column in the owning table points to the table 
containing the referred object. 

• 1 : n relationship (1 company, n departments) 

A 1: n relationship is resolved implicitly: within the table containing the n 
portion (departments) the key of the owning object (company) is used to 
resolve the relationship 

• inheritance 

Inheritance was not mapped to the database schema, that is, each table 
in the database contains all attributes of all inherited classes, and there 
is no special table representing the superclass. For example, if special 
company inherits from company, all attributes of company and special 
company are contained in one table — the special company table. In the 
future, if performance allows, mapping inheritance into the tables would 
be a good approach. The mapping would be resolved by foreign key 
relationships, where the inheriting table would have a foreign key that is 
the primary key of its parent table. Data would be retrieved through a 
join (possibly represented in a view), although updates (since they are 
not allowed on views or joins) would have to be done separately for each 
row resulting from inheritance contained in the join. The disadvantage of 
this approach is that it is slower than the approach where the inheritance 
of the object model is always collapsed into tables containing the whole 
inheritance hierarchy. This approach requires possibly multiple updates 
to circumvent the restriction of not being able to perform updates on 
joins and views. Additionally join operations tend to be the most time 
expensive operations in relational database systems. An advantage of 
this approach is that maintenance of the database would be much easier, 
because changes in class attributes would not spread across many 
tables. 

9.5.3 Performance Considerations 

The following considerations apply when using a relational database 
management system (RDBMS) to store persistent objects: 

9.5.3. 1 Static SQL 

Static SQL has the advantage of being faster than dynamic SQL, because 
queries are not interpreted (compiled) at run time. If the amount of data 
processed in relation to the number of queries made is large, the speed 
advantage of static SQL is negligible. 

9. 5. 3. 2 Dynamic SQL 

Dynamic SQL has the advantage of being more flexible, thus allowing for a wide 
variety of ad hoc queries. Dynamic SQL has the disadvantage of being slower 
than static SQL because queries are built and compiled at run time. The fact that 
queries are compiled at run time can result in speed improvements, because the 
query optimizer uses the current database state. This tends especially to be true 


120 Developing Distributed Object Applications 



in highly volatile databases. The flexibility of dynamic SQL also tends to reduce 
the amount of code to be written for the object to database mapping, because all 
the information necessary for building a select statement can be defined at run 
time. If the amount of data processed in relation to queries made is small, the 
speed disadvantage of dynamic SQL is large. Object queries, when defined by 
the user at run time, can almost always be managed with reasonable 
programming effort when dynamic SQL is used. 

9.5.3. 3 Multiuser Concurrent Access 

DSOM provides the mechanism of a server program. The server program, as 
previously described, is the place where objects are created or restored on 
behalf of the client. This process (the server program when in execution) acts as 
a database client to DB2. To have multiple clients access the same database 
concurrently, each client has its own server process where it can create, store 
and restore, or delete objects at will. Issuing DB2 transaction API calls, the client 
can also commit or roll back these changes to the database. 

When the SchemaMapper issues a query to read the object's data, it announces 
a read or write intent for the rows it is about to receive from the database. 
Objects are then materialized from the rows returned by the query. Any locks 
acquired are held for the time of the logical unit of work (LUW). 

9.5.4 Data Storage and Management 

We reused the database design of the previous project. The only thing we did 
was to separate the original database into two databases. 

Refer to Appendix C, “FCE Database Definitions” on page 167 for the database 
tables defined in both the client and server machines. 
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Chapter 10. Implementing the Distributed FCE Application 


Implementing a distributed application whose parts were developed to run on 
different systems adds to the complexity of the development process. 

We used the IDL approach to implement the FCE sample application (see 
Figure 65). 


Server Client 



* Class registration in Interface and Implementation Repositories 
is required only if DSOM is used. 


Figure 65. Application Building Using IDL 

The synchronization of the development of an application that spans 
heterogeneous environments is not an easy task. For a small project, team 
members can synchronize development by keeping one another informed. For a 
larger project, synchronization of development should be automated with the 
help of change management tools. 


© Copyright IBM Corp. 1996 
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10.1 Server Implementation 

This section presents the process of implementing a server by using the 
SOMobjects Developer Toolkit Version 2.1. The process focuses primarily on the 
creation of class interfaces written in IDL. 

Figure 66 on page 125 depicts the process: 

1. Write the class description in IDL. 

2. Register the classes in the SOM Interface Repository. 

Once the Interface Repository contains the class interface descriptions, 
implementation of the client can proceed in parallel with creating Smalltalk 
wrappers for SOM classes (see 10.2.1, “Generating VisualAge SOM Wrapper 
Classes for the Client” on page 139). Registration of the class interface 
descriptions in the Interface Repository is the prerequisite for the SOM 
support of VisualAge to derive wrapper classes from SOM classes. 

3. Generate and implement language bindings for C + + from IDL. 

4. Generate C + + program skeleton code from IDL. 

5. Implement the logic of the class methods in C + + . 

6. Compile the completed class source file. 

7. Make SOM class implementation available as a class library. 

8. Register class implementation with the DSOM Implementation Repository. 
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Figure 66. Server Implementation Process 


Before you can carry out the individual tasks of the server implementation 
process, you have to prepare the development environment. The environment 
setup primarily controls the operation of the tools, such as the SOM compiler, 
but it also can help foster cooperation between the development teams assigned 
for client implementation and server implementation. 

SOM and DSOM require several environment variables to be set before any 
class is registered in the SOM Interface Repository or DSOM Implementation 
Repository. 

For effective communication between the client development environment and 
the server development environment, a shared file system is recommended. A 
file system helps ensure that information needed on both sides is consistent. In 
particular the shared file system should include: 

• The SOM Interface Repository 

• The DSOM Implementation Repository 

• The IDL files that are ready for client use. 
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10.1.1 Write Class Description in IDL 

At this stage of the development process the object-oriented design model 
specifies the classes, their relationships, their attributes, and their methods. 
During implementation more classes are usually needed to keep implementation 
details separate from the essential classes of the model. 

The first cut of the IDL can be derived directly from the object-oriented design 
model. CASE tools are available that are capable of generating IDL directly from 
an object-oriented design model. When IDL is to be created without support of 
any tool, describing the class interface is a straightforward task. 

Some issues such as the relationships between classes and object initialization 
deserve special attention. 

10.1.1.1 Class Relationships 

Class relationships other than inheritance relationships can be implemented as 
attributes. The FCE application's design model contains the following class 
relationships: 

• One-to-one between Country and Currency 

• One-to-many between Customer and Account, and between Customer and 
Order 

• Aggregation between Order and Orderltem 

The following definitions can be used to represent the relationship in IDL: 

one-to-one A one-to-one relationship can be implemented by defining an 
attribute that is an object reference in both related classes. 

The one-to-one relationship between Country and Currency can 
be defined as: 

interface Country; 
attribute Country currency; 

One-to-many One-to-many relationships between classes can be reflected in 
IDL files in two different ways. 

The first one-to-many relationship is when the classes have a 
structural relationship ; that is, several classes are pieces of a 
"more complex class." In this case, the pieces tend to be 
referred to quite often during run time. Hence those objects 
should reside in memory, and the classes should be included 
inside the more complex class. For example, if class A has a 
one-to-many relationship with class B and class C, the following 
should be reflected in the IDL definitions of class A: 

attribute sequence<cl assB> classBs; 
attribute sequence<cl assC> classCs; 

In the FCE application, the relationship between SOMCustomer 
and SOMAccounts is a one-to-many relationship. The 
SOMCustomer has the following declared in its IDL file: 

attri bute<SOMAccount , 20> account Li st ; 

where 20 indicates that each customer can hold at most 20 
accounts under his or her name. 
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The second many-to-one relationship is when the one object 
" knows of the many objects” In this case, it is sufficient to have 
the one object hold the many objects' keys rather than having 
the many objects included in the one object. Thus, if 
SOMCustomer wants to "know of the SOMAccounts" he or she 
holds, the IDL file of SOMCustomer could have been declared 
like this: 

attribute <long, 20 accountIDList; 

aggregation Aggregation relationships between classes can be reflected in 
IDL files by defining an attribute that is a collection of objects in 
the aggregate class. The type of collection chosen depends on 
the intended use of the contained objects, such as an ordered or 
sorted sequence requirement. For example, in the FCE 
application, the Order class contains a number of Orderltems. In 
the IDL file for the Order class, the definition of the list of order 
items can be reflected like this: 

attribute sequence<0rderltem> orderList; 

10.1.1.2 Object Initialization 

SOM provides a somDefaultlnit method to initialize instance variables and 
attributes in a newly created object. It also provides a somDestruct method for 
cleanup when the Som object "dies." Both methods are similar to the 
constructor and destructor of the C++ language. 

We recommend that the somDefaultlnit and somDestruct methods always be 
overridden by the implementation classes. To override the two methods, make 
sure that override is specified for them in the implementation section of the SOM 
IDL files: 

implementation { 


somDestruct: override; 
somDefaultlnit: override; 


} 


10.1.2 Register Classes in SOM Interface Repository 

The SOM Interface Repository provides run-time access to all information in the 
IDL description of a class of objects. 

DSOM in particular requires that object classes that will be accessed from 
another process have their interfaces added to the Interface Repository. It uses 
the interface information when transforming local method calls on proxies into 
request messages transmitted to remote objects. 

The SOM support of VisualAge also uses the information in the Interface 
Repository to create wrapper classes from it. These wrapper classes in turn 
define the interface of SOM objects to the Smalltalk environment. 
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The Cashier class is registered in the Interface Repository by using the following 
command: 

sc -u -sir csh.idl 

A class that has not been registered in the Interface Repository causes DSOM to 
generate a run-time error when an attempt is made to invoke a method of that 
class. 

10.1.3 Generate Language Bindings for C++ 

Bindings make it easy for programmers to implement and use SOM classes. 

They define an interface to classes that enables programmers to declare objects 
and invoke methods in the same way they do for C++ objects. 

The SOM compiler generates two different kinds of C + + binding files out of IDL 
files: 

• Usage bindings provide the definitions needed to implement a client program 
using SOM classes. These usage binding files have the extension .xh. 

• Implementation bindings provide the internal view of SOM classes needed by 
the class implementer. The implementation binding files have the extension 
.xih. They include the usage binding files. 

Changes made to an IDL file are directly reflected in changes to the generated 
bindings. Therefore, each time IDL files are changed, the bindings must be 
regenerated. 

The SOM compiler generates both usage and implementation bindings for the 
class Cashier through the following command: 

sc -D PRIVATE -D SOMIDL -sxihtxh csh.idl 

where the macro -D PRIVATE causes the SOM compiler to omit everything 

marked as private by #ifdef PRIVATE in the IDL. Thus a public view is 

generated for use by clients. 

-D SOMIDL lets the SOM compiler make use of the implementation-specific 

definitions in the IDL, such as release order of methods and overridings. 

-sxih:xh specifies which emitter is going to be invoked by the SOM compiler to 
produce output. Here both usage bindings and implementation bindings are 
requested to be generated. 

10.1.4 Generate C++ Program Skeleton Code from IDL 

To assist users in implementing classes, the SOM compiler produces a C++ 
program skeleton file (also known as a template implementation file). This file 
contains all definitions and method prototypes that are needed for a class 
implementation, except the actual logic of the methods. 

Specify the C++ emitter (xc) on the invocation of the SOM compiler: 
sc -D PRIVATE -D SOMIDL -sxc csh.idl 

Before the business logic is implemented in the skeletons, stub DLLs are 
generated for the client through the C + + compiler. See 10.4.4, “Creating Stub 
DLLs” on page 149 for more details. 
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10.1.5 Generate DAX Objects for FCE SOM Bank Servers 

The SOM object classes require data access capabilities as part of their 
implemented logic. We can use the VisualAge C++ Data Access (DAX) objects 
to provide the SOM objects with the required data access capabilities. The DAX 
object of each SOM object can be generated by the DAX as part of VisualAge 
C + + Version 3. 

With the Data Access Builder we can graphically create a data access class for 
each table of the database. In this section, we describe how to generate the 
SOMCustomer data access object. The procedures for generating data access 
objects for SOMAccount and SOMBank are very similar. 

Before using the DAX builder you have to have the database in place and have 
the FCE userid as the qualifier for the database tables. 

1. Open the Data Access Builder from the VisualAge C + + tools folder. 

2. Click on the Create Classes push button from the Data Access Builder - 
startup window. 

3. The Create classes window appears (see Figure 67). 

4. Select CSOODB and click on the Connect push button. 

5. Select FCE. Customer and click on Create classes push button. 



Figure 67. Connecting to the FCE. CUSTOMER Table 


6. The Data Access Builder window appears (see Figure 68 on page 130) with 
a Customer icon representing the created customer data access class. 
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7. Click mouse button 2 on the Customer icon and choose Open settings to 
open the Settings notebook (refer to Figure 69). 

8. Change the Class name of the class from Customer to DaxCust, and close 
the Settings window. 


Class name DaxCust 

Fite stem DaxCust 

•: i : 

DaxCuSl V.hpp 
:• DaxCustY.cpp 
) DaxCust'/.sqc 
i DaxCust V.vho. 


Reset ; : Help 


3 5M 3 .it- ? ife 

■ : DclXCtJSl 1.1(11 

: : baxCustX.cpp 
; DaxCllStl.SC|C 
v DaxCustlmak 


V; C++ I argel Library iDaxCustV 
; SOM dliname 


| Attributes 


1 3*11 


Figure 69. Settings Notebook for Generated customer class 


9. Click mouse button 2 on the DaxCust icon from the Data Access Builder 
window (refer to Figure 70 on page 131) and choose Generate -> Parts to 
generate the required sources. 
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10. Exit the Data Access Builder window and choose Save when prompted. 

11. The generated .cpp and .hpp files can be found in the \IBMCPP\WORKING 
directory. 


10.1.6 Adding Business Logic 

Figure 71 shows the C++ code template of SOMAccount.CPP function template 
which was generated by the SOM compiler. 


/* 

* This file was generated by the SOM Compiler and Emitter Framework. 

* Generated using: 

* SOM Emitter emitxtm: 2.42 
*/ 

#i fndef S0M_Modul e_somacct_Source 
#def i ne S0M_Modul e_somacct_Source 
#endi f 

#define SOMAccount_Cl ass_Source 
#include "somacct.xih" 

/* 

*Method from the IDL attribute statement: 

*"attribute string accountNumber" 

*/ 

S0M_Scope string SOMLINK _get_accountNumber(SOMAccount *somSelf, 

Environment *ev) 

{ 

SOMAccountData *somThis = SOMAccountGetData(somSelf) ; 
SOMAccountMethodDebug("SOMAccount","_get_accountNumber") ; 

/* Return statement to be customized: */ 

{ string retVal ; return (retVal); } 


/* 

*Method from the IDL attribute statement: 
*"attribute string accountNumber" 


Figure 71 (Part 1 of 4). SOMAcct.CPP Function Template Generated by SOM Compiler 
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*/ 

SOM_Scope void SOMLINK _set_accountNumber(SOMAccount *somSelf, 

Environment *ev, 
string accountNumber) 

{ 

SOMAccountData *somThis = SOMAccountGetData(somSelf) ; 
SOMAccountMethodDebug("SOMAccount","_set_accountNumber") ; 


/* 

*Method from the IDL attribute statement: 

*"attribute string branchld" 

*/ 

S0M_Scope string SOMLINK _get_branchId(SOMAccount *somSelf, 

Environment *ev) 

{ 

SOMAccountData *somThis = SOMAccountGetData(somSelf) ; 
SOMAccountMethodDebug("SOMAccount","_get_branchId") ; 

/* Return statement to be customized: */ 

{ string retVal ; return (retVal); } 


/* 

*Method from the IDL attribute statement: 

*"attribute string branchld" 

*/ 

S0M_Scope void SOMLINK _set_branchId(SOMAccount *somSelf, 

Environment *ev, string branchld) 

{ 

SOMAccountData *somThis = SOMAccountGetData(somSelf) ; 
SOMAccountMethodDebug("SOMAccount","_set_branchId") ; 


/* 

*Method from the IDL attribute statement: 

*"attribute string accountDescription" 

*/ 

S0M_Scope string SOMLINK _get_accountDescription(SOMAccount *somSelf, 

Environment *ev) 

{ 

SOMAccountData *somThis = SOMAccountGetData(somSelf) ; 
SOMAccountMethodDebug ("SOMAccount","_get_accountDescri pti on" ) ; 

/* Return statement to be customized: */ 

{ string retVal; return (retVal); } 


/* 

*Method from the IDL attribute statement: 

*"attribute string accountDescription" 

*/ 

S0M_Scope void SOMLINK _set_accountDescription(SOMAccount *somSelf, 

Environment *ev, 
string accountDescription) 

{ 

SOMAccountData *somThis = SOMAccountGetData(somSelf) ; 
SOMAccountMethodDebug("SOMAccount","_set_accountDescription") ; 


Figure 71 (Part 2 of 4). SOMAcct.CPP Function Template Generated by SOM Compiler 
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} 

SOM_Scope void SOMLINK retrieve(SOMAccount *somSelf, Environment *ev) 

{ 

SOMAccountData *somThis = SOMAccountGetData(somSelf) ; 
SOMAccountMethodDebug ("SOMAccount", "retrieve") ; 

} 

S0M_Scope void SOMLINK update(SOMAccount *somSelf, Environment *ev) 

{ 

SOMAccountData *somThis = SOMAccountGetData(somSelf) ; 
SOMAccountMethodDebug("SOMAccount"," update") ; 

} 

S0M_Scope void SOMLINK add(SOMAccount *somSelf, Environment *ev) 

{ 

SOMAccountData *somThis = SOMAccountGetData(somSelf) ; 
SOMAccountMethodDebug("SOMAccount","add") ; 


/* 

* Following methods return specific information of this SOMAccount object 
*/ 

S0M_Scope void SOMLINK del (SOMAccount *somSelf, Environment *ev) 

{ 

SOMAccountData *somThis = SOMAccountGetData(somSelf) ; 
SOMAccountMethodDebug ("SOMAccount", "del") ; 


S0M_Scope boolean SOMLINK isCheckingAccount (SOMAccount *somSelf, 

Environment *ev) 

{ 

SOMAccountData *somThis = SOMAccountGetData(somSelf) ; 
SOMAccountMethodDebug("SOMAccount","isChecki ngAccount") ; 

/* Return statement to be customized: */ 

{ boolean retVal ; return (retVal); } 


S0M_Scope boolean SOMLINK isSavingsAccount (SOMAccount *somSelf, 

Environment *ev) 

{ 

SOMAccountData *somThis = SOMAccountGetData(somSelf) ; 
SOMAccountMethodDebug ("SOMAccount", "isSavingsAccount") : 

/* Return statement to be customized: */ 

{ boolean retVal; return (retVal); } 


/* 

* SOM/DSOM specific stuffs 
*/ 

S0M_Scope boolean SOMLINK isSuperSavingsAccount(SOMAccount *somSelf, 

Environment *ev) 

{ 

SOMAccountData *somThis = SOMAccountGetData(somSelf) ; 
SOMAccountMethodDebug("SOMAccount","isSuperSavingsAccount") ; 

/* Return statement to be customized: */ 

{ boolean retVal; return (retVal); } 


Figure 71 (Part 3 of 4). SOMAcct.CPP Function Template Generated by SOM Compiler 
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SOM_Scope void SOMLINK somDestruct (SOMAccount *somSelf, octet doFree, 

somDestructCtrl* Ctrl) 

{ 

SOMAccountData *somThis; /* set in BeginDestructor */ 
somDestructCtrl global Ctrl; 
somBooleanVector myMask; 

SOMAccountMethodDebug ("SOMAccount", "somDestruct") ; 

SOMAccount_Begi nDestructor; 

/* 

* local SOMAccount deinitialization code added by programmer 
*/ 

SOMAccount_EndDestructor; 

} 


S0M_Scope void SOMLINK somDefaul tlni t (SOMAccount *somSelf, somlnitCtrl* Ctrl) 

{ 

SOMAccountData *somThis; /* set in Beginlnitial izer */ 
somlnitCtrl gl obal Ctrl ; 
somBooleanVector myMask; 

SOMAccountMethodDebug ("SOMAccount", "somDefaul tlni t") ; 

SOMAccount_BeginIni ti al izer_somDefaul tlni t; 

SOMAccount_Ini t_SOMObject_somDefaul tlni t (somSel f , Ctrl ) ; 

/* 

* local SOMAccount initialization code added by programmer 
*/ 


Figure 71 (Part 4 of 4). SOMAcct.CPP Function Template Generated by SOM Compiler 

The SOMAccount. CPP file with our logic added to it is shown in the SOMAccount 
implementation listing in Appendix E, “SOM Objects Implementation Files” on 
page 183. 


10.1.7 SOMAccount Makefile 

The next step is to compile and link the completed class source files to make the 
SOM class implementation available as a class library. Figure 72 shows the 
makefile to build the SOMAccount class for the distributed FCE application. The 
makefiles for building other classes are similar to the makefile for the 
SOMAccount class. 


.all: SOMAcct.LIB \FCE\BIN\TestAcct.EXE 

SOMAcct.CPP: SOMAcct.IDL SOMAcct.XIH 
@echo " Compile :: SOM Compiler " 
sc.exe -sxc somacct.idl 
..\updateIR.CMD somacct.idl 

SOMAcct.XIH: SOMAcct.IDL SOMAcct.XH 
@echo " Compile :: SOM Compiler " 
sc.exe -sxih somacct.idl 


Figure 72 (Part 1 of 3). Makefile Used to Build SOMAccount Class 
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SOMAcct. XH: SOMAcct. IDL 

Gecho " Compile :: SOM Compiler " 
sc.exe -sxh somacct.idl 

DaxAcctv.c: DaxAcctv.SQC 

gecho " Compile :: SQL Precompile " 

sqlprep.exe DaxAcctv.SQC SOMBANK /B=\FCE\BIN\DaxAcctV . BND / P 

DaxAcctv.obj : DaxAcctv.c 

@echo " Compile :: C++ Compiler " 

icc.exe /I. /DSTATIC_LINK /Oc /Gm /Gd /Ge- /G4 /Fo"DaxAcctv.obj" 1C DaxAcctv.c 

DaxAccty.obj : DaxAccty.cpp DaxAcctv.hpp 
gecho " Compile :: C++ Compiler " 

icc.exe /I. /DSTATICLINK /Oc /Gm /Gd /Ge- /G4 /Fo"DaxAccty .obj" 1C DaxAccty.CPP 

SOMAcct.obj: SOMAcct.cpp 

gecho " Compile :: C++ Compiler " 

icc.exe /I. /DSTATICLINK /Oc /Gm /Gd /Ge- /G4 /Fo"SOMAcct.obj" / C SOMAcct.CPP 

SOMAcct. LIB: \FCE\BIN\SOMAcct.DLL 
gecho " Lib :: Import Lib " 
implib.exe SOMAcct. LIB \FCE\BIN\SOMAcct.DLL 
\FCE\BIN\SOMAcct.dll: \ 

DaxAcctv.obj \ 

DaxAccty.obj \ 

SOMAcct.obj \ 

SOMAcct. def 

echo " Link : : Linker " 
icc.exe g« 

/Tdp 

/B" Inoe" 

/Fe\FCE\BIN\SOMAcct.dl 1 

DaxAcctv.obj 

DaxAccty.obj 

SOMAcct.obj 

SOMTK. LIB 

SOMAcct. def 

« 

DLLRNAME \FCE\BIN\SOMAcct.DLL CPP0M30=FCE0M30 
DLLRNAME \FCE\BIN\SOMAcct.DLL CPP00B3=FCE00B3 
DLLRNAME \FCE\BIN\SOMAcct.DLL CPP0DS3 I = FCE0DS3 I 


\FCE\BIN\TestAcct.EXE: TestAcct.OBJ SOMAcct. LIB 
gecho " Link : : Li nker " 
icc.exe g« 

/Tdp 

/B" / roe" 

/ Fe\FCE\BIN\TestAcct.EXE 
TestAcct.OBJ 
SOMTK. LIB 
SOMAcct. LIB 

« 

DLLRNAME \FCE\BIN\TestAcct.EXE CPP0M30=FCE0M30 

TestAcct.OBJ: TestAcct.CPP 

gecho " Compile :: C++ Compiler " 

icc.exe /I. /DSTATICLINK /Oc /Gm /Gd /Ge+ /G4 /Fo"TestAcct.obj" 1C TestAcct.CPP 
clean: 

echo " Clean up all intermediate and target files..." 

-del *.obj 

-del \FCE\BIN\TestAcct.exe 
-del \FCE\BIN\DaxAcctv.bnd 


Figure 72 (Part 2 of 3). Makefile Used to Build SOMAccount Class 


Chapter 10. Implementing the Distributed FCE Application 135 





Figure 72 (Part 3 of 3). Makefile Used to Build SOMAccount Class 


10.1.8 Register Server Objects 

Register the server objects to DSOM repository through the pregimpl utility. You 
can also use the command line utility, regimpl. 

1. Add implementation alias. Select Add from the Implementations pull-down in 
the DSOM Implementation Registration window (see Figure 73). Fill in the 
Alias and the Host name accordingly. Host name is either the TCP/IP host 
name on the server machine or "localhost" if you want to put both the bank 
server and branch client on the same machine. 






2. Define the class to DSOM and map the classes to the aliases. Select Add 
from the Classes pull-down in the DSOM Implementation Registration window 
(see Figure 74). Put SOMCustomer in New Class Name for the SomCust 
alias. 

3. For DSOM Workstation, both the client and server run on the same machine. 
The above procedures are sufficient for them to interoperate. 

For DSOM WorkGroup, client and server run on different machines. For 
distributed objects to talk over DSOM, the implementation IDs must be 
identical. To generate identical implementation IDs: 

a. Make the client and server share the same implementation files through 
a shared file system. 

b. Copy the implementation files from one machine to the other. 

The implementation files are located in the directory pointing to the 
%SOMDDIR% environment variable. 



Figure 74. Adding a New Class and Mapping It to the Defined DSOM Alias 
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10.2 Client Implementation 

The client part of the application was developed entirely in VisualAge. 

The functions implemented in the client were those that enabled the cashier to: 

• Log on to the system 

• Query and update customer information 

The connection with the server part of the application was through the VisualAge 
wrapper classes. In our implementation, we extended the SOM wrapper classes 
(see discussions in 9.4.5, “Effects of Extending the SOM Wrapper Classes” on 
page 117 for precautions.). 

The presentation part of a nondistributed application is dependent on the model 
classes of that application for its business function and data. This is also true in 
a distributed application. By using DSOM, these classes are defined in the IDL 
statements. VisualAge SOMsupport can create the wrapper classes from 
compiled IDL statements, which are to be stored in the Interface Repository. 
Assuming that the Interface Repository exists and is stable enough to be used, a 
good sequence for implementing the client code is as follows (see Figure 75 on 
page 139): 

1. Set up the environment to use VisualAge and DSOM as described in 
Appendix B, “Setting Up the Implementation Platform” on page 161. 

2. Create the wrapper classes needed on the client side from the Interface 
Repository. 

3. Create the nonvisual parts by extending the SOM wrapper classes. 

4. Add the desired methods and variables and make the interface public with 
the VisualAge Public Interface Editor. 

5. Create the visual parts and composite visual parts and connect them to the 
other parts of the system. 

6. Create stub DLLs for all required DSOM wrapper classes. 

7. Test and iterate this process. 
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Figure 75. Client Implementation Process 


10.2.1 Generating VisualAge SOM Wrapper Classes for the Client 

VisualAge SOMsupport includes a framework of Smalltalk classes called the 
SOM Smalltalk Constructor. These classes provide the ability to generate the 
Smalltalk wrapper classes that represent SOM classes based on interface 
definitions that have been compiled from IDL files and stored in the SOM 
Interface Repository. Figure 42 on page 82 shows this process. 

To generate SOM wrapper classes, you can use the VisualAge visual interface or 
Smalltalk programmatic interface. Before generating SOM wrapper classes, 
ensure that the SOMsupport feature has been loaded into the VisualAge 
Smalltalk image on the client workstation. 
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10.2.1.1 Using the VisualAge Visual Interface 

The VisualAge visual interface enables you to create SOM wrapper classes or 
explore class structures as defined in the Interface Repository. 

To generate SOM wrapper classes through the VisualAge visual interface, follow 
this procedure for SOMCustomer (the procedures for SOMBank and 
SOMAccount are similar): 

1. Create an application to hold the SOM objects. We created an application 
named FCESOMObjects. 

2. Click with the mouse button 2 on the Parts container (as shown in Figure 76) 
and select Generate and then SOM Wrappers. 
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Figure 76. Generating a SOM Wrapper Class (Part 1) 


3. The Create SOM Wrappers window appears (Figure 77 on page 141). Scroll 
down the list box to find the SOMCustomer class. 5 Select SOMCustomer, 
click the DSOM: radio button, and then OK to generate the SOMWrapper. 


5 VisualAge obtains the information from the interface repositories of the system. And the information required was added by 
the SOM Compiler during the SOM compilation phase (that is, an option of -usir was specified when running SC. EXE against 
the corresponding IDL files). 
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Note: If there is an existing SOMCustomer wrapper class, the wrapper 
generator modifies only what has to be modified and does not change 
anything that you previously added. 
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Figure 77. Generating a SOM Wrapper Class (Part 2) 


10.2.1.2 Using the Smalltalk Programmatic Interface 

You can also use the programmatic interface to generate SOM wrapper classes 
by writing Smalltalk code. See the online reference book "VisualAge for 
Smalltalk: Features Class Guide and References," for details on generating 
wrapper classes through this interface. 


10.3 Modifying the FCE Application to Use SOM Objects 

This section describes the changes to some visual parts and some Smalltalk 
coding to extend the FCE application to use the SOM objects. 
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10.3.1 Visual Parts 

Figure 78 and Figure 79 on page 143 respectively show the CustomerQueryView 
before and after modification. Notice that few changes are required. In fact, a 
good design and analysis model results in minimum changes to the code of the 
client platform. 
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Figure 79. CustomerQueryView after Modification 


10.3.2 Script 

We removed all the direct database access logic in the original FCE application 
and instead obtained customer, bank, and account information from the 
respective SOM objects. 

Notice that the use of the objects to populate the views is the same for both 
"ordinary" Smalltalk objects and SOM objects. In fact, only the name we used 
indicates whether it is SOM object or not. 
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Figure 80. CustomerQueryView after Modification 


10.4 Using VisualAge Smalltalk SOMsupport 

This section describes some important points to consider when using the 
VisualAge Smalltalk SOMsupport to develop distributed object applications. 

10.4.1 Support of SOM Data Types 

SOMsupport Version 3.0 supports basic and composite SOM data types as well 
as some SOM-unique data types in addition to those specified in the CORBA 
specification. 6 


e The data representations from SOMsupport Version 2.0 continue to be supported when the Version 2.0 Migration Facility 
support is loaded. However, combining Version 2.0 data representations with Version 3.0 methods or Version 3.0 data 
representations with Version 2.0 methods is generally not supported. 
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10.4.1.1 Basic Data Types 

Figure 81 maps the SOM basic data types to their equivalent Smalltalk classes. 
A Smalltalk wrapper method requires as input, or returns as output, an object of 
the equivalent Smalltalk class. 


SOM 

Smal 1 tal k 

bool ean 

Boolean (true or false) 

char 

Character 

float 

Float 

double 

Float 

short 

Integer (between -32768, 32777) 

long 

Integer (between -2147483648, 2147483647) 

unsigned short 

Integer (between 0, 65535) 

unsigned long 

Integer (between 0, 4294967295) 

octet 

Integer (betwen 0, 255) 

stri ng 

Stri ng 


Figure 81 . Visual Age Smalltalk Equivalents of SOM Basic Data Types 


10.4.1.2 Composite Data Types 

Figure 82 maps the SOM composite data types to their equivalent Smalltalk 
classes. SOMsupport provides special classes for those SOM data types that 
have no direct Smalltalk equivalents. 


SOM 

Smalltalk or SOMsupport special 

Notes 

array 

Array 


□ 


enum 

SOMEnumerator 


B 


sequence 

OrderedCol lection 


B 


any 

(see notes) 


□ 


struct 

LookupTable (implicit) 


B 



unique subclass of Object (explicit) 



union 

Smalltalk object whose class 

B 


maps to one of the types 




in the union (implicit) 




instance of SOMUnion (explicit) 



poi nter 

(see notes) 


□ 

self 

(not supported) 



foreign 

parameters or return values 


B 


with foreign data types are 




passed as simple pointers 




Figure 82. VisualAge Smalltalk Equivalents of SOM Composite Data Types 


Notes: 


Note Q: SOMsupport does not support multidimensional arrays. 
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Note 0 : SOM enumerators map to instances of the Smalltalk 
SOMEnumerator class. These instances are stored in the 
CORBAConstants dictionary, keyed by their fully qualified names, and the 
SOMGIobals pool dictionary, keyed by their Smalltalk names. 

Instances of SOMEnumerator support the full range of comparison 
operations, as described in the OMG Smalltalk mapping specification, 
including <, < = , =, >, and > = . 

Note 0 : The OrderedCollection class has been extended with two 
instance methods: length and buffer. These methods correspond to the 
members of the structure used in the C or C++ bindings for sequences. 

Note Q: The actual value of any determines which Smalltalk class is 
used. An application can test the class of an incoming any to determine 
what it is. For an outgoing any parameter, you can pass any Smalltalk 
object that maps to a SOM type. 

Note 0 : The implicit binding takes maximum advantage of the dynamic 
nature of Smalltalk. It is the least intrusive binding for the Smalltalk 
programmer. The explicit binding retains the value of the discriminator, 
and provides greater control for the Smalltalk programmer (see 10.4.1.3, 
“Implicit and Explicit Binding” on page 147 for more details). 

• struct mapping with implicit binding: A SOM structure maps to 
LookupTable, a subclass of Dictionary. The key for each structure 
member is an atom, whose value is the name of the member 
converted to Smalltalk naming conventions. 

• struct mapping with explicit binding: If a SOM struct specifies explicit 
binding, the structure is mapped to a uniquely named subclass of 
Object. The class name is the fully qualified name of the structure 
converted to Smalltalk class name syntax. 

Note 0 : A SOM union maps in one of two ways, depending on whether 
the IDL file specifies explicit or implicit binding for the union: 

• union mapping with implicit binding: The value of the union maps to a 
Smalltalk object whose class maps to one of the types in the union. 

• union mapping with explicit binding: A SOM union maps to an 
instance of SOMUnion. You then interact with this object to set or 
retrieve the actual value, or to change the discriminator, through the 
methods provided by the SOMUnion object. 

Note 0 : In general, Smalltalk handles all necessary pointer conversions 
so programmers can deal directly with the object representing the data 
being pointed to on the Smalltalk side. 

However, SOMsupport deals with some special cases. For example, some 
SOM methods accept a NULL pointer as input or can return a NULL 
pointer. If you specify nil as an input parameter, a NULL pointer is passed 
to SOM. Likewise, any SOM method that creates an object (such as 
somNew) returns a NULL pointer if the object cannot be created. 

Another special case is associated with parameters or returned values 
that are specified in IDL as void*. In this case, the pointer itself is the 
data, so it must be preserved. 
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Note 0: SOM foreign data is not fully described in the SOM Interface 
Repository. Thus, SOMsupport cannot correctly map foreign types to 
Smalltalk class equivalents. Parameters or return values that have 
foreign data types are passed in and out of Smalltalk as simple pointers. 
The SOMsupport application and the SOM object implementation must 
ensure the validity of these pointers by copying data where necessary. 

10.4.1.3 Implicit and Explicit Binding 

For the struct and union data types, SOMsupport recognizes a modifier that 
controls the type of mapping to Smalltalk objects. Implicit binding is the default; 
the IDL file is not modified for implicit binding. 

To set explicit binding, use the SOM modifier, ssc_explicit_mapping, in the 
implementation section of the IDL file. For example, the following partial IDL 
specification sets explicit binding for a union named foo\ 

interface FuObject : SOMObject 

{ 

attribute union foo; 

#ifdef SOMIDL 

implementation 

{ 

releaseorder : _get_foo, _set_foo; 
ssc_expl ici t_mapping : foo; 


10.4.2 Memory Management 

Because SOM objects exist outside the Smalltalk address space, Smalltalk's 
built-in memory-management facilities cannot control the allocation and freeing 
of memory used for SOM objects. As a result, several special 
memory-management considerations apply to applications that use SOM objects. 

10.4.2.1 Freeing Objects 

A Smalltalk object exists as long as it is in use. When an object is no longer 
referenced by any other object, the Smalltalk system automatically destroys it 
and frees the memory associated with it. 

SOM objects, however, exist outside the Smalltalk image in ordinary system 
memory. Therefore, when a SOM object is no longer needed, your application 
must explicitly destroy the object and free the associated memory. 

If the SOM object is used in the VisualAge Composition Editor, you can connect 
the closedWidget event of your main view to the somFree action of any SOM 
objects in the view. This connection generates an operation that destroys the 
SOM object when the view closes. 

10.4.2.2 Passing Pointers 

The absolute memory address of a Smalltalk object can change dynamically as 
the Smalltalk memory-management system reallocates storage. Therefore, 
Smalltalk objects cannot be referenced by address. This presents a problem 
when Smalltalk objects are supplied as parameters to SOM method calls 
because pointers to Smalltalk objects cannot be safely passed outside the 
Smalltalk environment. 
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To handle this situation, a wrapper method that takes arguments does not 
directly pass to SOM objects pointers to Smalltalk objects. Instead, it copies 
each Smalltalk object's data into SOM memory, where its address remains 
constant. The wrapper also passes a pointer to the copied data to the SOM 
method. 

This copy persists only for the duration of the method call. Therefore, a SOM 
object must not cache pointers to this data for reference during subsequent 
method calls. Instead, it must make its own copy of the data and refer to that 
copy. 

10.4.2.3 Copying Parameter Values 

Any SOM object method that receives parameters from Smalltalk must perform a 
deep copy of the parameter values. This requirement applies to local objects as 
well as object located on a remote machine. For example, if a SOM object 
method takes as a parameter a structure containing a string, the method must 
make a copy of the string, rather than simply copying the pointer value. 

The reason for the deep copy is that any pointers passed outside the Smalltalk 
image are pointers to copies of the original data, and these copies exist only for 
the duration of the method call. The result of a shallow copy of a pointer, 
therefore, is a pointer to freed memory. 

The default set method implementation generated by the SOM compiler performs 
only a shallow copy. When implementing a SOM object that you intend to use 
with SOMsupport, do not use the default SOM set method for any data type that 
involves indirection, such as pointers and strings, or structures that contain 
them. You can control this by specifying the noset modifier in your IDL. 

10.4.3 Exception Handling 

SOMsupport Version 3.0 maps SOM exceptions to Smalltalk ExceptionalEvents, 
extending the full power of Smalltalk exception handling to SOM exceptions. 
Unlike SOMsupport Version 2.0, you do not have to resume from a walkback in 
order to clear the SOM exception. 

Here is the Smalltalk exception tree for SOM exceptions: 

ExAll 

' ExCORBASystem' 

: StExcep: :BAD_0PERATI0N' 

: StExcep: : INITIALIZE' 

: StExcep: : MARSHAL' 

' ExCORBAUser' 

' : : SOMUserCl assA: :SOMUserExceptionr 
' : : SOMUserCl assA: :S0MUserException2' 

' : : SOMUserCl assA: :S0MUserException3' 


The CORBAConstants dictionary contains these exception definitions, using the 
fully qualified exception name as the key. The SOMGIobals pool dictionary 
contains these exception definitions, using the Smalltalk names as the key. 

ExCORBASystem and ExCORBAUser serve as the root for their respective 
subtrees and provide the default SOM exception handlers. These default 


148 Developing Distributed Object Applications 



handlers report a resumable error to the active process. Complete information 
for both System and User exceptions is provided in the signal arguments. 

IDL allows each operation to include information about the kinds of run-time 
errors that may be encountered. This information is specified in exception 
definitions that declare the name of the exception, and an optional error 
structure to be returned if the exception is detected. For example, look at the 
partial IDL interface specification for SOMCustomer: 

#include <somobj.idl> 

#include <snglicls.idl> 

interface SOMCustomer: SOMObject 

{ 

// exception to be rasied on problem, 
exception SOMCustomer_Excep { 
long errCode; 
char reason [ 81 ] ; 

}; 


SOM exceptions will be handled automatically by the SOMsupport code as 
described above unless you specify alternative handling. The default handling is 
designed for a development environment. You can code a specific exception 
handler for the raised exception if you want to override the default handling for 
run time (see the online reference book "VisualAge for Smalltalk: Features Class 
Guide and References," for examples of coding exception handlers). 

10.4.4 Creating Stub DLLs 

SOM needs the stub DLLs to access the class data structure of objects at run 
time. Stub DLLs are generated from the C++ skeleton files, which are 
obtained from IDL through the SOM compiler in the server implementation 
process. 

The stub DLLs are obtained through the C++ compiler; no business logic is 
added to the implementation skeletons. Because stub DLLs do not contain 
business logic, their size is considerably smaller than the application DLLs 
(APP.DLLs). 

10.4.5 Redirecting SOM Character Output to Smalltalk 

SOM provides a set of APIs that SOM objects can use to create printed output. In 
VisualAge Version 2.0 SOMsupport, the only way to see this output was to start 
IBM Smalltalk or VisualAge with STDOUT redirected to a file: abt > stdout.som 
or ibmst > stdout.som. However, using this mechanism, the output cannot be 
seen until the file closes, which happens when IBM Smalltalk or VisualAge is 
shut down. Because SOM trace output is usually produced for debugging, 
having to end an IBM Smalltalk or VisualAge session in order to see the trace 
output can have a significant impact on programmers' productivity. VisualAge 
V.3 SOMsupport includes a new class, SOMOutChar, to support the character 
output redirection function. 
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The easiest way to use this function is to redirect SOM character output to the 
T ranscript : 7 

SOMOutChar on: Transcript 

All output from the SOM print routines now appears on the Transcript until the 
redirection ends: 

SOMOutChar close 

You can also see the SOM trace output in its own window: 

SOMOutChar on: 

(EtWorkspace new label: 'SOM Trace Output'; open) 

To make the most effective use of SOMOutChar support, you can wrap your use 
of output redirection in an exception handler (see the online reference 
"VisualAge for Smalltalk: Features Class Guide and Reference," for more details 
about this wrapping technique). 

10.4.6 Setting Up an Individual Test Environment 

Testing the client part of a distributed application requires that the developer to 
consider whether to test with or without the server part. Although the final 
integration test has to be performed with the complete system, there are times 
when testing the client without the server is desirable. 

10.4.6.1 Testing the Client Code without the Server 

Many variations are possible for setting up a test environment where server 
code is not active. One elegant way can be used when the aggregation scheme 
as proposed in this book is followed. When the aggregation is established, if a 
test class is obtained instead of a wrapper class, a test environment without a 
server can be established. These test classes must have all methods of the 
wrapper classes they replace and return values good enough to enable the tests. 
It may be worthwhile to automate this mechanism. 

10.4.6.2 Testing the Client Code with the Server 

While testing the client part of the application, instances of SOM wrapper classes 
are created. This causes DSOM to consult both the Interface Repository as well 
as the Implementation Repository in the course of creating server objects on the 
server machine and proxies on the client machine. 

The Implementation Repository is queried to find the server implementation's 
host and implementation ID. This implementation ID is passed to the DSOM 
daemon on the server machine, where it is used to query the Implementation 
Repository to start the correct server program. 

Because the implementation ID has to be identical in both queries, the setup of 
the test environment should ensure that the information used to create the 
implementation ID is shared between client and server machines. An easy way 
to ensure consistent information is to share a file system between participating 
systems. The shared file system keeps the valid copies of the Interface 
Repository and Implementation Repository for testing. 


7 When using SOMOutChar capability, you can get into situations where you get a large volume of output that you do not really 
want. In such situations, you can execute a system break (Alt+SysReq) to stop Smalltalk. 
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Another very important point to remember is to verify the existence of stub DLLs 
before starting the test, as described in the SOMObjects Developers Toolkit 
User's Guide and in 10.4.4, “Creating Stub DLLs” on page 149. 

10.4.7 Additional Considerations 

Listed below are additional points to consider when using VisualAge Smalltalk 
SOMsupport to develop distributed object applications. 

• If you test both the client and server in the same OS/2 machine, you can 
omit the installation of SOMObjects Toolkit V2.1. The SOMObjects Base 
Toolkit is sufficient for DSOM Workstation. The following are applicable for 
VisualAge C + + Version 3.0: 

- VisualAge Smalltalk V3 SOMsupport is shipped with SOMobjects Toolkit 
at CSD 2.1.2. However, SOMobjects shipped with VisualAge C + + V3 is 
at CSD 2.1.1. If you do not apply CSD 2.1.2, VisualAge SOM wrapper 
generation will not work properly. 

- You will probably have a problem running the DSOM environment 
because of a missing file, SOMSEC.DLL. You have to obtain the file from 
SOMObjects Toolkit V2.1 or from workstations that have the file. 

- You have to modify the SOMCORBA.CMD and SOMXH.CMD files in the 
\IBMCPP\BIN directory and modify the %SOMBASE%\INCLUDE 
reference to the %SOMBASE%\INCLUDE\SOM directory. 

- A number of IDL files are located in the \IBMCPP\INCLUDE directory 
rather than in the \IBMCPP\INCLUDE\SOM directory. You have to copy 
them to the SOM directory to build the corresponding header files before 
running SOMCORBA.CMD and SOMXH.CMD. 

- Ensure that SOMCORBA.CMD, followed by SOMXH.CMD, is run before 
you do any C++ development. 

• The generated makefiles from Project Smartz did not fit our requirements for 
building the server DLLs. However, you can use Project Smartz to generate 
a makefile and manually edit it to suit your requirements (see 10.1.7, 
“SOMAccount Makefile” on page 134). 

• For the FCE application, we commented out the line 

#pragma 1 braryf'DaxyyyyV. LIB") 
in the DaxyyyyV.hpp, where yyyy can be oust, bank, or acct. 


• If you make any modifications in the IDL file that affect the releaseorder or 
the signature of the interfaces, you have to regenerate the corresponding 
SOM wrapper class in VisualAge Smalltalk. Failure to do so will cause 
problems in the Smalltalk environment, 

• Whenever possible, use a simple C or C++ program to test the SOM server 
objects that you developed. Try not to use VisualAge Smalltalk to test an 
unstable server program. 

• If you have a SOM object with sequence as the attribute take great care 
when wrapping it in the VisualAge Smalltalk environment. The sequence will 
be mapped to a Smalltalk OrderedCollection class. However, as the 
Collection in Smalltalk is unbounded, the maximum value for the sequence is 
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set to 0. If you take the maximum value of the sequence attribute and use it, 
problems could occur on the server side. 

• Exercise caution when handling the memory pointers on the server side. 
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Chapter 11. Looking Ahead 


Most object-oriented applications today are either stand-alone applications 
accessing database servers, or as front-ends to legacy applications. However, 
to unleash the full power of object technology, we have to build distributed object 
applications with interoperability among objects on heterogeneous platforms. 

The distributed objects can interact if they conform to a universally accepted 
object architecture. This interaction mechanism is defined by an ORB. CORBA 
2.0 defines interoperable ORBs, which enable ORBs from different vendors to 
interoperate. 

IBM has embraced CORBA, the OMG-defined architecture, and has delivered 
DSOM, a complete CORBA-compliant implementation of an ORB. The 
SOMObjects Toolkit enables programmers to build DSOM-based distributed 
applications. However, the complexity of the toolkit requires special skills to 
build real-world distributed object applications. 

The technology is evolving, and the IBM products are starting to provide facilities 
to ease the implementation of distributed object applications. The VisualAge 
Smalltalk SOMsupport facilities the use of SOM objects, and the direct-to-SOM 
compile options of VisualAge C++ compilers help the application programmer 
concentrate on the business logic and not spend too much time on the tedious 
implementation details. 

Other facilities soon to be seen stem from the new SOM frameworks, such as 
the Persistence Framework, which helps decouple the object application from 
the complexities of the underlying repository where the persistent objects are 
stored. Other frameworks will provide transaction and unit of work management. 

One of the major requirements for distributed applications is a distributed 
debugging facility, because today, when errors occur in a distributed system, it is 
quite difficult to find the faulty software component. 

Another requirement is a facility to handle configuration management of source 
code in a distributed environment when clients and servers use different library 
systems. 
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Appendix A. Requirements Specifications 

This appendix describes the requirements specifications for the Foreign 
Currency Exchange application. 

A.1.1 Branch Functions 

Because smaller branches do not maintain their own stocks of foreign currency 
and travelers checks, they can satisfy demand only by ordering from the center 
on the customer's behalf. Larger branches do maintain stocks, and customer 
sales and purchases are handled by cashiers allocated to a foreign currency and 
travelers check “bureau” within the branch. 

Functions performed at the branch include: 

• Customer order management 

- Customer purchases from branch cashier 

This is the most frequently performed function in this application. 
Purchases are normally for one currency and one check for the 
destination country. Payment for this service can be by cash, credit 
card, local check, or a debit to the customer's account. 

Stock levels are reduced, a customer tab is printed, and accounting 
entries are passed to the accounts application. 

Other facilities of this function are: 

- Check stock levels 

- Reduce branch stock level 

- Determine currency and/or check denominations (small, mix, large, 
or specified) 

- Obtain exchange rate 

- Print tab (duplicate for signature) 

- Generate accounting entries (debit currency code and credit dollars 
branch account) 

- Flandle multiple currencies 

- Handle multiple currencies and checks 

- Handle country restrictions, warnings, general information 

- Customer sells to branch cashier 

Note: This function is not implemented in the application. 

Tourists and travelers returning with excess currency and checks sell or 
cash in currency and checks to the bank. Notes and checks are checked 
for forgeries by reference to textual information on legitimate 
denominations, descriptions, and known forgery defects. Other activities 
in this function are: 

- Obtain exchange rates 

- Increase branch stock level 

- Print tab (duplicate for signature) 

- Handle multiple currencies 
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- Handle multiple currencies and checks 

- Pass accounting entries (debit currency codes and credit dollars 
branch account) 

- Customer order form that cannot be satisfied 

Note: This function is not implemented in the application. 

Not all branches stock currencies and checks. Very few branches stock 
the full range as this would not be economical. All orders that cannot be 
met by the branch are routed to the center. If payment has been made 
or the customer has an account with the bank, the currencies or checks 
will be sent to the customer's address; otherwise they will be sent to the 
branch for later collection. Other activities in this function are: 

- Handle country restrictions, warnings, general information 

- Handle currency and/or check denominations (small, mix, large, or 
specified) 

- Handle multiple currencies 

- Handle multiple currencies and checks 

- Obtain exchange rate 

- Take deposit if noncustomer 

- Print tab (duplicate for signature) 

- Pass accounting entries (debit currency code and credit dollars 
branch account) 

• Cashier management 

- Cashier stock reconciliation 

At the end of each day, or more frequently, each cashier must verify that 
the checks and foreign currency in his or her cabinet are equal to the 
totals held in the system. This is done by viewing the values for each 
denomination held, within each currency or check. 

If these totals cannot reconcile, the discrepancy is passed to an Overs 
and Shorts account, and the totals are amended accordingly. 

Authority can be granted only by a supervisor. 

Activities include: 

- Obtain exchange rate for each currency or check 

- Display each currency or check totals and local currency equivalent 

- Display each currency or check denomination totals and local 
currency equivalent 

- Order replenishment stock if minimum stock quantity reached 

- Send excess stock to center if maximum stock quantity exceeded 

- Display total local currency equivalent 

- Raise compensating accounting entries for small losses or gains 

- Archive reconciliation 

• Branch management 

Note: The branch management functions are not implemented in the 
application. 
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Branch stock replenishment 


At the end of each day, the requests of the cashiers are consolidated. 
Each request can be an order either to replenish stock or to send excess 
stock. A consolidated branch order is then sent to the center. 

- General inquiry of branch stocks 

Similar to customer order (branch) but no update intent 

- General inquiry of central stocks 

Similar to customer order (center) but no update intent 

- Forgery recognition (computer image) 

Inquiry only (compare image to real note and verify descriptive 
information on which faults to look for) 

A.1.2 Center Functions 

The center is responsible for supplying foreign currency and travelers checks to 
the branches (outlets) and selling off excess foreign currency received from 
branches. The center does this by dealing on the foreign currency markets, 
arranging bulk shipments at favorable exchange rates. 

Functions performed at the center include: 

• Bank management 

Note: The bank management functions are not implemented in the 
application. 

- Branch order 

Orders from branches are typically for several currencies and checks. All 
orders are processed in batch mode, bulk quantities are picked, delivery 
arrangements are made, postal charges are set, stock levels are 
reduced, and accounting entries are passed between branch and the 
central accounts. 

Branch order functions include: 

- Currency and/or check denominations (small, mix, large, or 
specified). 

- Check stock levels 

• Single currency 

• Single checks 

• Multiple currencies 

• Multiple checks 

• Multiple currencies and checks 

- Print picking lists 

- Reduce center stock level 

- Obtain exchange rate 

- Weigh packages and establish postal charges 

- Print branch documents 


Appendix A. Requirements Specifications 157 



- Pass accounting entries (debit currency code credit dollars center 
account). 

- Customer order 

Where branches have been unable to satisfy any part of the customer 
order, the whole order is supplied by the center. Purchases are typically 
for one currency and one check for the destination country. 

If payment for this service has been made at the branch, the foreign 
currency and travelers checks will be mailed to the customer; otherwise, 
they will be mailed to the branch for collection. 

Stock levels are reduced, a customer tab is printed, and accounting 
entries are passed to the accounts application. 

Customer order functions include: 

- Handle country restrictions, warnings, general information 

- Handle currency and/or check denominations (small, mix, large, or 
specified) 

- Handle check stock levels 

- Handle single currency 

- Handle single checks 

- Handle multiple currencies 

- Handle multiple checks 

- Handle multiple currencies and checks 

- Print picking lists 

- Reduce center stock level 

- Weigh packages and establish postal charges 

- Obtain exchange rate 

- Print customer tab 

- Pass accounting entries (debit currency code credit dollars center 
account) 

- Branch excess 

Excess foreign currency received from the branches is counted, 
reconciled with branch delivery record, and added to central stocks. 
Where the customer has not accepted an order sent by the center to the 
branch for collection, reversing accounting entries for this cancellation or 
return is passed. 

Customer order functions include: 

- Add to central stock 

- Match value to branch file 

- Pass accounting entries 

- Reverse entry for cancellations and/or returns. 

- Central stock reconciliation 

At the end of each day, or more frequently, the center verifies that the 
checks and foreign currency in its stocks are equal to the totals held in 


158 Developing Distributed Object Applications 



the system. This is done by viewing the values for each denomination 
held, within each currency or check, and counting the actual stock. 

If these totals cannot reconcile, the discrepancy is passed to an Overs 
and Shorts account, and the totals are amended accordingly. 

Authority can be granted only by the senior manager. 

Activities include: 

- Obtain exchange rate for each currency and/or check 

- Display each currency and/or check totals and local currency 
equivalent 

- Display each currency and/or check denomination totals and local 
currency equivalent 

- Order replenishment, if minimum stock quantity reached, from other 
banks (United States and abroad) through the foreign note dealers 

- Sell excess, if maximum stock quantity is exceeded, to other banks 
(United States and abroad) through the foreign note dealers 

- Display total local currency equivalent 

- Raise compensating accounting entries for small losses and/or gains 

- Archive reconciliation 
Maintain branch stock limits 

Periodically the stock held at each branch is reviewed to check whether 
the stock minimum and maximum levels are still appropriate. A number 
of "what if" conditions are used to establish a revised set of limits, 
including seasonal, period on period, and general demand conditions. 

Stock limit processing includes: 

- General inquiry stock levels still valid? 

• Season change, period on period demand change, abnormal 
condition, and so forth 

- Change stock level minimum or maximum 

- Add or remove stock type or denomination 
Maintain center stock limits 

Similar to branch but includes issues of bulk transport, international 
availability, and capacity. 

Maintain exchange rates 

Dealers maintain the rates for each currency and check by comparing 
with other banks' rates, general market rates from Reuters, Telerate, and 
the like, and by checking general availability. 

A different rate may be applied for small and large denominations. 

Miscellaneous transactions 

- Maintain forgery images 

- Create, amend, delete currency images 

- Produce customer labels, envelopes, documents 

- Produce branch sack labels and documents 
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Appendix B. Setting Up the Implementation Platform 


This appendix presents the hardware and software prerequisites for developing 
and implementing the FCE DSOM application. 

B. 1.1.1 Recommended Hardware 

The following hardware provided acceptable performance for development in our 
FCE DSOM case study: 

• Client machine 

- IBM PS/2 486, 50 MHz, 32 MB RAM, 120 MB or more DASD 

• Server machine 

- IBM PS/2 486, 50 MHz, 32MB RAM, 250 MB or more DASD 

B.1.1.2 Required System Software 

The following required software products were installed: 

• Client machine 

- OS/2 Warp V3 

- TCP/IP OS/2 V2.0 

- VisualAge for Smalltalk OS/2 V3.0 

- SOMObjects WorkGroup Enabler V2.1 8 

- DB2/2V1.2 

• Server machine 

- OS/2 Warp V3 

- TCP/IP OS/2 V2.0 

- VisualAge C + + for OS/2 V3.0 

- SOMObjects WorkGroup Enabler V2.1 8 

- DB2/2V1.2 

We used TCP/IP as the means of communication between client and server 
machines. NetBIOS or IPX can also be used. 


8 SOMObjects WorkGroup Enabler is required for DSOM Workgroup (that is, for communication between two machines). If 
DSOM Workstation is used, SOMobjects Workgroup Enabler is not required. 


© Copyright IBM Corp. 1996 


161 



B.2 Setting Up the Server System 

Figure 83 shows an overview of how the server application is implemented on 
the server machine. 



Install HW/SW 
OS/2 Warp V3, 
TCP/IP OS/2 V2.0 
DB2/2 VI. 2 
VisualAge C++ V3 
SOMobjects Toolkit V2.1 
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Prepare Environment 
Modify CONFIG.SYS 
TCP/IP Customization 
SOM/DSOM Customization 
DB2/2 Customization 
Build DataBase 
Bind Bind Files to Database 




Code IDL 

Generate SOM files 
Generate Data Access Object 
Adding Logics 
Compile 
Link 

Test and Debug 
Package 


Figure 83. Implementation of Server Application 


We carried out the following steps to develop the bank server (see Figure 83). 
For detailed programming code, see Appendix E, “SOM Objects Implementation 
Files” on page 183. 

1. Prepare environment 

All of the server files were located in the D:\FCE directory. The 
subdirectories of the D:\FCE directory were: 

• BIN - contained the actual executable of the servers. (For the client 
machine, it contained the exported library file of the VisualAge Smalltalk 
application.) 

• SOMSRV - contained sources of servers. 

• DATABASE - contained the exported IXF files and batch programs to 
re-create the databases. 

2. Install and set up the following required software (refer to the installation 
manuals accompanying the software): 

• OS/2 Warp V3 

• TCP/IP for OS/2 V2.0 

• DB2/2V1.2 

• VisualAge C + + for OS/2 V3 
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• SOMObjects WorkGroup Enabler V2.1 (for DSOM Workgroup) 

• Fixes (for SOM/DSOM, the level was SM21001) 

• Create a userid FCE with password: PASSWORD 
3. Modify CONFIG.SYS file 

After you modify the CONFIG.SYS file, reboot the machine before performing 
step 4. 

a. Add D:\FCE\BIN to the LIBPATH statement: 

LIBPATH=. ;C:\0S2; ;D:\FCE\BIN 

b. Add D:\FCE\SOMBANK.IR to the SOMIR statement: 

SET SOMI R=D :\IBMCPP\ETC\SOM . I R; ; D : \FCE\SOMBANK. I R 

c. If there is a ;SOMIR; statement in the SOMIR environment variable, 
remove it. 

d. Add the following two environment variables: 

SET SOMSOCKETS=TCPIPSockets 
SET USER=FCE 

e. Ensure that the following line is not present in CONFIG.SYS. If it is, 
remove it by changing: 

SET SMADDSTAR=1 

to 

REM SET SMADDSTAR=1 

f. Ensure that the following environment variables are set: 

SET HOSTNAME=xxxxYYYY 
SET ETOzzzz 

where xxxxYYYY is the host name of the client machine, and zzzz is the 
directory where you can find the HOSTS file. 

g. If the SOMobjects WorkGroup Enabler is installed, you might have to do 
the following: 

1) Remove the MPTN settings if you use the TCP/IP package installed 
before (MPTN is installed if NetBIOS support is chosen.) 

2) Ensure that the SOM\LIB directory of the WorkGroup Enabler is 
referenced before the \IBMCPP\DLL directory in the LIBPATH setting. 

3) Ensure that the SOM\BIN directory of the WorkGroup Enabler is 
referenced before the \IBMCPP\BIN directory in the PATH setting. 

h. Prepare SOM/DSOM development environment 

Run the following commands from an OS/2 command prompt to build the 
SOM header files: 

SOMCORBA.CMD 

This command makes the SOM header files conform to the CORBA 
standard 

SOMXH.CMD 

This command generates header files required for C+ + 
programming 

i. Build the database in the server machine 
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Run the following command file to create the server database: 
NEWSRVDB.CMD 

You have to use the Query Manager to add the primary key for 
CUSTOMER with CUST_ID, and primary key for ACCOUNT with ACCT_ID. 
Also add a foreign key of CUSTJD of CUSTOMER to CUSTJD of 
ACCOUNT, with cascade delete capability. 

j. Bind the DaxSQL.BND bind file to the database. DAXSQL.BND can be 
found in the \IBMCPP\BND directory: 

SQLBIND D:\IBMCPP\DAXSQL.BND SOMBANK /G=PUBLIC 

4. Define the IDL 

We used the following IDLs: SOMBank.lDL, SOMCustomer.lDL, and 
SOMAcct.lDL (see Figure 55 on page 109). 

For a complete listing of the SOMAcct.lDL file, see Appendix D, “SOM IDL 
Interface Listings” on page 175. 

5. Compile the IDL files 

Use the SOM Compiler to compile the IDL files to generate the SOMxxxx.xih, 
and SOMxxxx.cpp files, as well as update the SOM repository file. Refer to 
10.1.7, “SOMAccount Makefile” on page 134 for the makefiles. 

6. Create the data access objects 

Use the Data Access Builder of VisualAge C++ V3 to create the data 
access objects (see 10.1.5, “Generate DAX Objects for FCE SOM Bank 
Servers” on page 129). 

7. Modify the generated .CPP files with our logic for the server objects. Refer to 
Appendix E, “SOM Objects Implementation Files” on page 183 for details. 

Note that when you return information from a pointer, special considerations 
apply. The SOM object does not just return the pointer. Rather it allocates a 
piece of memory, copies the contents of the object to which the pointer 
points in the allocated memory, and returns it. It is DSOM's responsibility to 
free the allocated memory, as defined by CORBA. The method does not free 
the pointer itself. 

8. Build the server stub DLLS (used for client machines). 

9. Build the server DLLs. 

10. Bind the following bind files fore SOMBANK database: 

• DaxAcctV.BND (generated during the build process) 

• DaxCustV.BND (generated during the build process) 

11. Register the server objects to the DSOM repository. 

12. If symbolic names are to be used in the DSOM registration, the 
%ETC%\HOSTS file must exist, and the addresses of both workstations must 
be defined in the file. 

The client and server machines must refer to the sample implementation ID. 
Thus, they have to share either the same set of DSOM implementation files 
or a drive, or one of the machines has to copy the files from the other. 

13. Start the DSOM daemon 

Start an OS/2 command session and type SOMDD. Minimize the session 
when the SOMDD-Ready message appears. 
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B.3 Setting Up the Client System 

We carried out the following steps to develop the branch client workstation 
system. 

1. Install and set up the following software (refer to the installation manuals 
accompanying the software): 

a. OS/2 Warp V3 

b. TCP/IP for OS/2 V2.0 

c. DB2/2 VI .2 

d. VisualAge for Smalltalk for OS/2 V3.0 

e. SOMObjects WorkGroup Enabler V2.1 (for DSOM WorkGroup) 

f. SOMObjects fixes (the level was SM21001) 

g. Create a userid FCE 

2. Modify CONFIG.SYS 

a. Add D:\FCE\BIN to the LIBPATFI statement: 

LIBPATH=. ;C:\0S2; ;D:\FCE\BIN 

VisualAge Smalltalk still requires a stub DLL for the DSOM wrapper 
object. 

b. Add D:\FCE\SOMBANK.IR to the SOMIR statement: 

SET SOMI R=D :\IBMCPP\ETC\SOM . I R; ; D : \FCE\SOMBANK. I R 

In our case study, we copied the SOMBANK.IR file from the server 
machine. In other situations, for example, if the client and server are on 
different platforms, you might have to take the IDL files on the server and 
compile them using the SOM Compiler to update the Interface Repository 
file of the client platform. 

c. Remove the ;SOMIR; statement in the SOMIR environment variable if it 
exists. 

d. Add the following two environment variables: 

SET SOMSOCKETS=TCPIPSockets 
SET USER=FCE 

e. Ensure that the following enviornment variables are set: 

SET HOSTNAME=xxxxYYYY 
SET ETOzzzz 

f. If the SOMobjects WorkGroup Enabler is installed, you might have to do 
the following: 

1) Remove the MPTN settings if you use the TCP/IP package is installed 
before (MPTN is installed if NetBIOS support is chosen). 

2) Ensure that the SOM\LIB directory of the SOMobjects WorkGroup 
Enable is referenced before the \IBMCPP\DLL directory in the 
LIBPATH setting. 
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3) Ensure that the SOM\BIN directory of the SOMobjects Work Group 
Enabler is referenced before the \IBMCPP\BIN directory in the PATH 
setting. 

3. If symbolic names are to be used in the DSOM registration, the 
%ETC%\HOSTS file must exist, and the addresses of both workstations must 
be in defined in the file. 

4. Start the DSOM daemon 

Start an OS/2 command session and type SOMDD. Minimize the session 
when the SOMDD-Ready message appears. 

5. Start VisualAge Smalltalk V3. Ensure that the SOMsupport feature and the 
original nondistributed FOE application are loaded. 

6. Create a VisualAge application called FCEScMObjects. 

7. Generate the SOM wrapper classes for each server class; namely, 

SOMBank, SOMCustomer, and SOMAccount. 

8. Modify the original nondistributed FCE application (see 10.2, “Client 
Implementation” on page 138 for details.) 

9. Test the application 9 

10. Package the application 


9 For our case study, modification of the original nondistributed FCE application to make it a distributed object application with 
Bank, Customer, and Account objects running in another server took only one day. 
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Appendix C. FCE Database Definitions 


This appendix lists the data definition languages that define the tables used in 
the FCE sample application and the REXX command files used for their creation. 

There are two databases used in the DSOM version of the FCE application, 
namely, CSOODB and SOMBANK. 

The CSOODB database contains all the tables listed below and is used by the 
branch client system. The CUSTOMER and ACCOUNT tables were not used. They 
exist to maintain compatibility with the previous nondistributed version of the 
FCE application. 

The SOMBANK database contains the CUSTOMER and ACCOUNT tables used by 
the bank server system. 


C.1 Data Definition Language for Relational Tables 

ACCOUNT Table 

CREATE TABLE ACCOUNT 


(ACCT ID 

CHAR(9) 

NOT NULL, 

ACCT TYPE 

CHAR(14) 

NOT NULL, 

ACCT BALANCE 

FLOAT 

NOT NULL, 

ACCT BRID 

CHAR(4) 

NOT NULL, 


PRIMARY KEY (ACCT_ID) , 

FOREIGN KEY ACCTBRCH (ACCTJ3RID) 

REFERENCES BRANCH ON DELETE RESTRICT) 

BRANCH Table 


CREATE TABLE BRANCH 


(BRCH ID 

CHAR (4) 

NOT NULL, 

BRCH NAME 

CHAR(20) 

NOT NULL, 

BRCH STREET 

CHAR(40) 

NOT NULL, 

BRCH CITY 

CHAR (16) 

NOT NULL, 

BRCH STATE 

CHAR (2) 

NOT NULL, 

BRCH ZIP 

CHAR(5) 

NOT NULL, 


PRIMARY KEY (BRCHID) 
BRANCH RESERVE Table 

CREATE TABLE BRANCHRESERVE 


(BRSV ID 

CHAR (4) 

NOT NULL, 

BRSV BRID 

CHAR(5) 

NOT NULL, 

BRSV TOTAL 

FLOAT 

NOT NULL, 


PRIMARY KEY (BRSV_ID), 

FOREIGN KEY BRSVBRCH (BRSV_BRID) 

REFERENCES BRANCH ON DELETE RESTRICT) 


CASHIER Table 
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CREATE TABLE CASHIER 

(CASHID CHAR(6) NOT NULL, 

CASH_FNAME CHAR(16) NOT NULL, 

CASH_LNAME CHAR(24) NOT NULL, 

CASH_BRID CHAR(4) NOT NULL, 

PRIMARY KEY (CASHID) 

FOREIGN KEY CASHBRCH (CASH_BRID) 

REFERENCES BRANCH ON DELETE RESTRICT) 


CASHIER DRAWER Table 


CREATE TABLE CASHIERDRAWER 

(CDRWID CHAR(4) NOT NULL, 

CDRW_CAID CHAR(6) NOT NULL, 

CDRW_SIZE CHAR(9) , 

CDRW_SLOTS I NT, 

PRIMARY KEY (CDRW_ID), 

FOREIGN KEY CDRWCASH (CDRW_CAID) 

REFERENCES CASHIER ON DELETE RESTRICT) 


COUNTRY Table 


CREATE TABLE COUNTRY 

(CNTYJAME CHAR(30) NOT NULL, 
CNTY_ID CHAR(3) NOT NULL, 
PRIMARY KEY (CNTYJAME) 


CURRENCY Table 


CREATE TABLE CURRENCY 


(CURR ID 


CHAR (3) 

NOT 

NULL, 

CURR NAME 


CHAR(16) 

NOT 

NULL, 

CURR CNTY 


CHAR(30) 

NOT 

NULL, 

LU 

1— 

c 

Cd 

X 

Cd 

ZD 

C_) 

BUY 

DEC (8,4) 

NOT 

NULL, 

CURR XRATE 

SELL 

DEC (8,4) 

NOT 

NULL, 

CURR FORG ' 

INFO 

CHAR(40) , 



CURR DESC 


CHAR(80) , 




PRIMARY KEY (CURR_ID), 

FOREIGN KEY CURRCNTY (CURRJNTY) 

REFERENCES COUNTRY ON DELETE CASCADE) 

CUSTOMER ORDER Table 

CREATE TABLE CUSTOMERORDER 


(CORD ID 

I NT 

NOT NULL, 

CORD CREATED 

CHAR(8) 

NOT NULL, 

CORD STATUS 

CHAR(4) 

NOT NULL, 

CORD TOTAL 

FLOAT 

NOT NULL, 

CORD CAID 

CHAR(6) , 


CORD CUID 

I NT 

NOT NULL, 
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PRIMARY KEY (CORD_ID), 

FOREIGN KEY CORDCASH (CORD_CAID) 

REFERENCES CASHIER ON DELETE SET NULL, 
FOREIGN KEY CORDCUST (CORD_CUID) 

REFERENCES CUSTOMER ON DELETE RESTRICT) 


CUSTOMER Table 

CREATE TABLE CUSTOMER 


(CUST ID 

INT 

NOT NULL, 

CUST ACID 

CHAR(9) , 


CUST FNAME 

CHAR(16) 

NOT NULL, 

CUST LNAME 

CHAR(24) 

NOT NULL, 

CUST STREET 

CHAR(40) 

NOT NULL, 

CUST CITY 

CHAR(16) 

NOT NULL, 

CUST STATE 

CHAR(2) 

NOT NULL, 

CUST ZIP 

CHAR(5) , 


CUST HPHONE 

CHAR(8) 

NOT NULL, 

CUST WPHONE 

CHAR (8) 

NOT NULL, 


PRIMARY KEY (CUST_ID), 

FOREIGN KEY CUSTACCT (CUST_ACID) 

REFERENCES ACCOUNT ON DELETE RESTRICT) 


DENOMINATION Table 


CREATE TABLE DENOMINATION 
(DNOM_ID 
DNOM_TYPE 
DNOM_VALUE 
DNOM_DESC 

PRIMARY KEY (DNOM ID, 


CHAR (3) NOT NULL, 
CHAR(8) NOT NULL, 
INT NOT NULL, 
CHAR(60) , 

DNOM TYPE, DNOM VALUE), 


FOREIGN KEY DNOMCURR (DNOM_ID) 

REFERENCES CURRENCY ON DELETE CASCADE) 


ORDERITEM Table 


CREATE TABLE ORDERITEM 
(ORDI_ORID 
ORDIJD 
ORDI_TYPE 
ORDI_VALUE 
ORDI_QTY 

ORDI_FORGN_TOTAL 
ORDI_LOCAL_TOTAL 
PRIMARY KEY (ORDI_ORID, 


INT 

NOT NULL, 

CHAR (3) 

NOT NULL, 

CHAR (8) 

NOT NULL, 

INT 

NOT NULL, 

INT 

NOT NULL, 

FLOAT 

NOT NULL, 

FLOAT 

NOT NULL 


ORDIJD, ORDIJYPE, ORDI_VALUE) 


STOCKITEM Table 
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CREATE TABLE STOCKITEM 


(STKI DRID 

CHAR (4) 

NOT NULL, 

STKI ID 

CHAR (3) 

NOT NULL, 

STKI TYPE 

CHAR(8) 

NOT NULL, 

STKI VALUE 

I NT 

NOT NULL, 

STKI QTY 

I NT 

NOT NULL, 

STKI MIN 

I NT 

NOT NULL, 

STKI MAX 

I NT 

NOT NULL 


PRIMARY KEY (STKI_DRID, STKI_ID, STKI_TYPE, STKI_VALUE) , 
FOREIGN KEY STKIDNOM (STKI_ID, STKI_TYPE, STKIJ/ALUE) 
REFERENCES DENOMINATION ON DELETE RESTRICT) 


C.2 Relational System Build Programs 

The REXX programs listed below can be used to create the CSOODB database. 

C.2.1 Database Creation REXX Command File 

/* this is a REXX command file which will */ 

/* create the CSOODB database */ 

if RxfuncqueryQ SQLEXEC') <> 0 then 
rcy = Rxf uncadd (' SQLEXEC' , ' SQLAR' , ' SQLEXEC' ) 
if RxfuncqueryQ SQLDBS') <> 0 then 
rcy = Rxf uncadd ('SQLDBS',' SQLAR', 'SQLDBS') 

say 'Starting DB2/2 Processing' 
call SQLDBS 'START DATABASE MANAGER' 
if (SQLCA.SQLCODE <> -1026) then 
rcy = ERR0R(); 

prodName = 'Visual Age' 
dbname = ' CSOODB' 
codeOK = 'nil' 

say 'Stopping any database currently in use' 
call SQLDBS 'STOP USING DATABASE'; 
if (SQLCA.SQLCODE <> -1024) then 
rcy = ERRORQ; 

say ' Dropping Database (' dbname ')' 
call SQLDBS 'DROP DATABASE' dbname 
if (SQLCA.SQLCODE = 0000) | (SQLCA.SQLCODE = -1013) then 
codeOK = 'yes' 

else 

rcy = ERRORQ; 

if (codeOK = 'yes') then 
do; 

say ' Creating Database (' dbname ')' 

call SQLDBS 'CREATE DATABASE ' dbname 

if (SQLCA.SQLCODE <> 0000) then 
dbCreated = 'yes' 


170 Developing Distributed Object Applications 



else 

rcy = ERROR (); 

say ' Opening DataBase (' dbname ')' 

call SQLDBS ' START USING DATABASE' dbname 
rcy = ERROR (); 

say ' Closing Database (' dbname ')' 
call SQLDBS 'STOP USING DATABASE'; 
rcy = ERROR (); 

if (dbCreated = 'yes') then 
do; 

say ' ' 

say 'A new database (' dbName ') was just created!!' 
say 'This database must be bound to the' prodName 'DLL!' 
end; 

say 'Completed DB2/2 Processing' 
end; 

rcy = Rxfuncdropf SQLEXEC') 
rcy = RxfuncdropC SQLDBS') 
exit; 

ERROR: 

if (RESULT = 0 & SQLCA.SQLCODE = 0) then 
return 0; 

say ' RESULT = ' RESULT; 

say 'SQLCA.SQLCODE = ' SQLCA.SQLCODE; 
say ' SQLMSG = ' SQLMSG; 

call SQLDBS 'STOP USING DATABASE'; 
exit; 

C.2.2 Table Creation REXX Command File 


/* this is a REXX command file which will */ 
/* drop then create a sample table */ 

if Rxfuncqueryf SQLEXEC') <> 0 then 
rcy = Rxf uncadd (' SQLEXEC' , ' SQLAR' , ' SQLEXEC' ) 
if Rxfuncqueryf SQLDBS') <> 0 then 
rcy = Rxf uncadd ('SQLDBS', 'SQLAR', 'SQLDBS') 

say 'Start DB2/2 Processing' 
call SQLDBS 'START DATABASE MANAGER' 
if (SQLCA.SQLCODE <> -1026) then 
rcy = ERROR(); 

prodName ='VisualAge' 

dbname = ' CSOODB' 

table = substitute table name 

call SQLStmts 

say ' DB2/2 database disconnect' 
call SQLDBS 'STOP USING DATABASE'; 
if (SQLCA.SQLCODE <> -1024) then 
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rcy = ERRORQ; 


say ' OPENING DATABASE (' dbname ')' 
call SQLDBS 'START USING DATABASE' dbname 
rcy = ERROR (); 

say ' Dropping Table (' itemTable ')' 
call SQLEXEC 'PREPARE si FROM :dropTbl_stmt' 
rcy = ERRORQ; 
call SQLEXEC ' EXECUTE si' 

if (SQLCA.SQLCODE <> 0000) & (SQLCA.SQLCODE <> -204) then 
rcy = ERRORQ; 

say ' Creating Table (' itemTable ')' 
call SQLEXEC 'PREPARE si FROM :crtTabl e_stmt' 
rcy = ERRORQ; 
call SQLEXEC ' EXECUTE si' 

if (SQLCA.SQLCODE <> 0000) & (SQLCA.SQLCODE <> -601) then 
rcy = ERRORQ; 

say ' CLOSING DATABASE (' dbname ')' 
call SQLDBS 'STOP USING DATABASE'; 


rcy = Rxfuncdropf SQLEXEC') 
rcy = Rxfuncdropf SQLDBS') 
say 'Completed DB2/2 processing' 
exit; 


SQLStmts: 


crtTabl e_stmt = Table DDL Statements 

dropTbl_stmt = ' DROP TABLE ' substitute table name 

return 

ERROR: 

if (RESULT = 0 & SQLCA.SQLCODE = 0) then 
return 0; 

say ' RESULT = ' RESULT; 

say 'SQLCA.SQLCODE =' SQLCA.SQLCODE; 
say ' SQLMSG = ' SQLMSG; 

call SQLDBS 'STOP USING DATABASE'; 
exit; 


C.2.3 Table Load REXX Command File 


/* this is a REXX command */ 

/* that will load i.e. populate a test table */ 

if Rxfuncqueryf SQLEXEC') <> 0 then 
rcy = Rxfuncaddf SQLEXEC', 'SQLAR', 'SQLEXEC') 
if Rxfuncqueryf SQLDBS') <> 0 then 
rcy = Rxfuncaddf SQLDBS',' SQLAR',' SQLDBS') 

table = substitute table name 

say 'Start DB2/2 load processing' 
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call SQLDBS 'START DATABASE MANAGER' 
if (SQLCA.SQLCODE <> -1026) then 
rcy = ERROR (); 

say ' Loading table ( 'table' )' 

call SQLDBS 

'import to csoodb from a:\csdb\cnty.del of del insert 
into country messages cnty.txt' 

if (SQLCA.SQLCODE <> 0000) & (SQLCA.SQLCODE <> 3107) then 
rcy = ERROR (); 


say 'Complete DB2/2 load processing' 

ERROR: 

if (RESULT = 0 & SQLCA.SQLCODE = 0) then 
return 0; 

say ' RESULT = ' RESULT; 

say 'SQLCA.SQLCODE = ' SQLCA.SQLCODE; 
say ' SQLMSG = ' SQLMSG; 

call SQLDBS 'STOP USING DATABASE'; 


exit; 
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Appendix D. SOM IDL Interface Listings 


Figure 84 through Figure 87 on page 178 contain the interface descriptions, 
written in IDL, for the SOM classes. 


D.1 SOMAccount Interface 


#i fndef D_SOMACCT_IDL 
#define D_SOMACCT_IDL 

#include <somobj .idl> 

#include <snglicls.idl> 

interface SOMAccount: SOMObject 

{ 

exception SOMAccount_Excep { 
long errCode; 
char reason [81] ; 


/* Followings match original attributes in FCE V 2 */ 
attribute string<9> accountNumber; 

attribute float balance; 

attribute string<4> branchld; 

attribute string<14> accountDescription; 

void 
void 
void 
void 

lifdef SOMIDL 

implementation { 
releaseorder: 

_get_accountNumber, _set_accountNumber, 
_get_balance, _set_bal ance, 

_get_branchld, _set_branchld, 

_get_accountDescri pt i on , _set_accountDescri pti on , 
retrieve, update, 
add, del; 

branchld: noset, noget; 

accountNumber: noset, noget; 

accountDescription: noset, noget; 

cal 1 style = idl ; 

dll name = "SOMAcct.dll"; 

somDestruct: override; 
somDefaultlnit: override; 

memory _management = corba; 

passthru C_xh_after = "#include <SOMAcctE.h>"; 
passthru C_xih_after = "#include <SOMAcctI.h>"; 

}; 

#endi f 

}; 


#endi f 


Figure 84. SOMAccount Interface 


retrieve]) ; 
update() ; 
add ( ) ; 
del (); 
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D.2 SOMBank Interface 


#i fndef D_SOMCUST_IDL 
#define D_SOMCUST_IDL 

finclude <somobj.idl> 
linclude <sngl i cl s. i dl> 


// forward desclarations 
interface SOMCustomer; 
interface SOMAccount; 
interface SOMCurrency; 
interface SOMBranch; 


interface SOMBank: SOMObject 

{ 

// exception to be rasied on problem. Not implemented yet 
exception SOMBank_Excep { 
long errCode; 
char reason [81] ; 


//# Followings match original attributes in FCE V 2 
attribute string name; 

//# one to many association 
sequence<SOMCustomer> customers () ; 
sequence<SOMCurrency> currencies () ; 

sequence<SOMBranch> SMbranches () ; //# named SOMbranches instead of 

//# branches to avoid the locally 
//# implementated method in 
//# FCE application only 

//# Followings are added for more complete functionality 
sequence<SOMAccount> accounts (); 


//# return a list of ids instead of the customer itself 

sequence<long> al ICustomerlds () ; 

sequencer tri ng> al 1 Account Ids () ; 

sequencer tri ng> al 1 Branch I ds() ; 

sequence<stri ng> al ICurrencylds () ; 

//# return a list of ids from a dynamic SQL statement 
sequence<long> matchingCustomerIds(in string clause); 

sequence<string> matchingAccountIds(in string clause); 
sequence<string> matchingBranchIds(in string clause); 
sequence<string> matchingCurrency!ds(in string clause); 


// SOM specific details 

lifdef SOMIDL 

implementation { 

releaseorder: _get_name, _set_name, 

customers, 
currencies, 

SMbranches, 
accounts, 

al 1 Customer Ids, matchingCustomerlds, 
al 1 Account Ids, matchingAccountlds, 
allBranchlds, matchingBranchlds, 

Figure 85 (Part 1 of 2). SOMBank Interface 
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al 1 Currency Ids, matchingCurrencylds; 
name: noset, noget; 


cal 1 style = idl ; 

dll name = "SOMBank.dll"; 

somDestruct: override; 
somDefaultlnit: override; 

memory _management = corba; 

//# take out the comments for debug 
passthru C_xh_after = "#include <SOMBankE.h>"; 
// include the application implementation header 
passthru C_xih_after = "#include <S0MBankI .h>"; 

}; 

#endi f 

}; 

#endi f 


Figure 85 (Part 2 of 2). SOMBank Interface 


D.3 SOMCurrency Interface 


#i fndef D_SOMCURY_IDL 
#define D_SOMCURY_IDL 

#include <somobj.idl> 
#include <snglicls.idl> 


interface SOMCurrency: SOMObject 
{ 

exception SOMCurrency_Excep { 


long 

errCode; 


char 

}; 

reason [81] ; 


attribute 

string<3> 

currencyld; 

attribute 

string<16> 

name; 

attribute 

string<30> 

country; 

attribute 

float 

xRateBuy; 

attribute 

float 

xRateSel 1 ; 

attribute 

string<40> 

forglnfo; 

attribute 

string<80> 

description 

void 

retrieve() ; 


void 

update]) ; 


void 

add ( ) ; 


void 

del (); 


lifdef SOM IDL 



implementation { 

releaseorder: _get_currencyld, _set_currencyld, 
_get_name, _set_name, 
_get_country, _set_country, 
_get_xRateBuy, _set_xRateBuy , 


Figure 86 (Part 1 of 2). SOMCurrency Interface 
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_get_xRateSel 1 , _set_xRateSel 1 , 

_get forglnfo, set_forgInfo, 

_get_description, _set_descri ption, 
retrieve, update, 
add, del; 

currencyld: 

noset, noget; 

name: 

noset, noget; 

country: 

noset, noget; 

forglnfo: 

noset, noget; 

description: 

noset, noget; 

call style = 

idl ; 

dll name = "SOMCury .dl V'; 

somDestruct: 

override; 

somDefaultlnit: override; 

memory _management = corba; 

passthru C xh 

after = "#include <SOMCURYE.h>"; 

passthru C_xih_after = "#include <SOMCURYI.h>"; 

}; 

#endi f 

}; 


#endi f 



Figure 86 (Part 2 of 2). SOMCurrency Interface 


DA SOMCustomer Interface 


#i fndef D_SOMCUST_IDL 
#define D_SOMCUST_IDL 

#include <somobj.idl> 
#include <sngl i cl s . i dl > 

// forward desclarations 
interface SOMAccount; 


interface SOMCustomer: SOMObject 

{ 

// exception to be rasied on problem. Not implemented yet 
exception SOMCustomer_Excep { 
long errCode; 


char 

h 

reason [81] ; 


attribute 

long 

customerld; 

attribute 

string<16> 

firstName; 

attribute 

string<24> 

1 astName; 

attribute 

string<8> 

homePhone; 

attribute 

string<8> 

workPhone; 

attribute 

string<40> 

street; 

attribute 

string<16> 

ci ty; 

attribute 

string<2> 

state; 

attribute 

string<5> 

zip; 

attribute 

string<9> 

accountld; 


Figure 87 (Part 1 of 3). SOMCustomer Interface 


178 Developing Distributed Object Applications 






attribute SOMAccount account; 

string accountNum() ; 

float accountBal ance() ; 

// Not used in current branch clients 

attribute sequence<string,20> accountldList; //#Each customer has at most 

//# 20 accounts 

attribute sequence<S0MAccount,20> accountList; //#Each customer has at most 

//# 20 accounts 

//# one to many association 
sequence<SOMAccount> accounts (); 


//# retrieve information for myself, from the database 
void retrieve(); 

//# update myself for the new information set to me to the database 
void update(); 

//# add myself to the database 
void add(); 

//# remove myself from the database 
void del () ; 


//# find all accounts that are belonged to myself from the database 
void getAl 1 AccountldsForSel f() ; 

void getAl 1 AccountsForSel f() ; 


//# SOM specific details 

#i fdef SOMIDL 

implementation { 
releaseorder: 


_get_customerId, 

_get_account, 

_get_fi rstName, 

_get_lastName, 

_get_homePhone, 

_get_workPhone, 

accountNum, 

accountBal ance, 

_get_street, 

_get_ci ty, 

_get_state, 

_get_zip, 

_get_accountId, 

_get_accountLi st 


_set_customerId, 
_set_account, 
_set_fi rstName, 
_set_l astName, 
_set_homePhone, 
_set_workPhone, 


_set_street, 
_set_city, 
_set_state, 
_set_zip, 
_set_accountId, 
set accountList, 


_get_accountIdList,_set_accountIdLi st, 

accounts, 

retrieve, 

update, 

add, 

del , 

getAl 1 AccountsForSel f, 
getAl 1 AccountldsForSel f; 


account: noset, noget; 
fi rstName: noset, noget; 
lastName: noset, noget; 
homePhone: noset, noget; 
workPhone: noset, noget; 

street: noset, noget; 
city: noset, noget; 


Figure 87 (Part 2 of 3). SOMCustomer Interface 
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state: noset, noget; 

zip: noset, noget; 

accountld: noset, noget; 

_get_accountLi st: object_owns_resul t; 

_set_accountl_ist: object_owns_parameters = "_accountl_i st"; 

_get_accountIdList : object_owns_resul t; 

_set_accountIdLi st: object_owns_parameters = "_accountIdl_i st"; 

cal 1 style = idl ; 

dll name = "SOMCust.dll"; 

somDestruct: override; 
somDefaultlnit: override; 

memory _management = corba; 


//# SOMCustE.h contains the enum for errors 
passthru C_xh_after = "#include <SOMCUSTE.h>"; 

//# SOMCustl.h defines implementation specific information for the 
//# customer 

passthru C_xih_after = "#include <SOMCUSTI.h>"; 


}; 

#endi f 

}; 


#endi f 


Figure 87 (Part 3 of 3). SOMCustomer Interface 


D.5 SOMCustomerManager Interface 


#i fndef D_SOMCUST_IDL 
#define D_SOMCUST_IDL 

finclude <somobj.idl> 

#include <snglicls.idl> 

interface SOMCustomer; 

interface SOMCustomerManager: SOMObject 

{ 

exception SOMCustMgr_Excep { 
long errCode; 
char reason [81]; 


// attribute sequence<SOMCustomer> items; 


void 

refresh () ; 

void 

select]); 

long 

numCustomersO ; 

long 

takeFirstCustomerId() ; 

long 

takeLastCustomerldf) ; 

long 

takeNextCustomerldf) ; 


Figure 88 (Part 1 of 2). SOMCustomerManager Interface 
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long takePreviousCustomerldO ; 

lifdef SOMIDL 

implementation { 

releaseorder: refresh, select, 
numCustomers, 
takeFirstCustomerld, 
takeLastCustomerld, 
takeNextCustomerld, 
takePreviousCustomerld; 

//# _get_i terns, _set_i terns; 

cal 1 style = i dl ; 

dll name = "SOMCMgr.dll"; 

somDestruct: override; 
somDefaultlnit: override; 

memory _management = corba; 

// metaclass = SOMMSinglelnstance; 

passthra C_xh_after = "#include <SOMCMgrE.h>"; 
passthru C_xih_after = "#include <SOMCMgrI.h>"; 

}; 

#endi f 

}; 

#endi f 


Figure 88 (Part 2 of 2). SOMCustomerManager Interface 
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Appendix E. SOM Objects Implementation Files 


Figure 89 through Figure 93 on page 218 list the files used to implement the 
SOM objects with the template files generated by the SOM compiler. 


E.1 SOMAccount Implementation 


/* 

* This file was generated by the SOM Compiler. 

* Generated using: 

* SOM incremental update: 2.42 
*/ 

/* 

* This file was generated by the SOM Compiler and Emitter Framework. 

* Generated using: 

* SOM Emitter emitxtm: 2.42 
*/ 

#i fndef S0M_Modul e_somacct_Source 
#def i ne S0M_Modul e_somacct_Source 
#endi f 

#define SOMAccount_Cl ass_Source 

#def i ne SOMMSi ngl eInstance_Cl ass_Source 

#include "SOMAcct.xih" 


/* 

*Method from the IDL attribute statement: 

*"attribute string accountNumber" 

*/ 

S0M_Scope string SOMLINK _get_accountNumber (SOMAccount *somSelf, 

Environment *ev) 

{ 

SOMAccountData *somThis = SOMAccountGetData(somSelf) ; 
SOMAccountMethodDebug ("SOMAccount", "_get_accountNumber") ; 

if (somThi s->accountNumber == NULL) { 

somThi s->accountNumber = (string) S0MMalloc(2) ; 
strcpy (somThi s->accountNumber," "); 

} 


string accountNumber = (string) SOMMalloc(strlen(somThis->accountNumber)+l) ; 
strcpy (accountNumber, somThi s->accountNumber) ; 
return accountNumber; 


/* 

*Method from the IDL attribute statement: 
*"attribute string accountNumber" 

*/ 


S0M_Scope void 

{ 


SOMLINK _set_accountNumber (SOMAccount *somSelf, 
string accountNumber) 


Environment *ev, 


Figure 89 (Part 1 of 5). SOMAccount Implementation 
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SOMAccountData *somThis = SOMAccountGetData(somSelf) ; 
SOMAccountMethodDebug("SOMAccount","_set_accountNumber") ; 

if (accountNumber != NULL) { 

if (somThis->accountNumber ! = NULL) SOMFree(somThi s->accountNumber) ; 
somThi s->accountNumber = (string) SOMMal loc(strlen(accountNumber)+l) ; 
strcpy(somThis->accountNumber, accountNumber) ; 

} 

else { 

// should raise exception here 

} 


/* 

*Method from the IDL attribute statement: 

*"attribute string branchld" 

*/ 

S0M_Scope string SOMLINK _get_branchId(SOMAccount *somSelf, 

Environment *ev) 

{ 

SOMAccountData *somThis = SOMAccountGetData(somSelf) ; 
SOMAccountMethodDebug("SOMAccount","_get_branchId") ; 

if (somThi s->branchld == NULL) { 

somThi s->branchld = (string) S0MMalloc(2) ; 
strcpy(somThis->branchId," "); 

} 

string branchld = (string) SOMMal loc(strlen(somThis->branchId)+l) ; 
strcpy (branchld, somThi s->branchld) ; 
return branchld; 


/* 

*Method from the IDL attribute statement: 

*"attribute string branchld" 

*/ 

S0M_Scope void SOMLINK _set_branchId(SOMAccount *somSelf, Environment *ev, 

string branchld) 

{ 

SOMAccountData *somThis = SOMAccountGetData(somSelf) ; 
SOMAccountMethodDebug("SOMAccount","_set_branchId") ; 

if (branchld != NULL) { 

if (somThis->branchId != NULL) SOMFree(somThi s->branchld) ; 
somThi s->branchld = (string) SOMMal loc(strl en(branchld)+l) ; 
strcpy(somThis->branchId, branchld) ; 

} 

else { 

// should raise exception here 



/* 

*Method from the IDL attribute statement: 
*"attribute string accountDescription" 

*/ 


S0M_Scope string 
{ 


SOMLINK _get_accountDescription(SOMAccount *somSelf, 
Environment *ev) 
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SOMAccountData *somThis = SOMAccountGetData (somSel f) ; 

SOMAccountMethodDebug ("SOMAccount","_get_accountDescri pti on" ) ; 

if (somThis->accountDescription == NULL) { 

somThis->accountDescription = (string) SOMMal 1 oc(2) ; 
strcpy (somThis->accountDescri pti on," ") ; 

} 

string accountDescription = (string) SOMMal loc(strl en(somThi s->accountDescription)+l) ; 
strcpy (accountDescri pti on, somThis->accountDescription) ; 
return accountDescription; 


/* 

*Method from the IDL attribute statement: 

*"attribute string accountDescription" 

*/ 

S0M_Scope void SOMLINK _set_accountDescription(SOMAccount *somSelf, 

Environment *ev, string accountDescription) 

{ 

SOMAccountData *somThis = SOMAccountGetData(somSelf) ; 

SOMAccountMethodDebug ("SOMAccount","_set_accountDescri pti on" ) ; 

if (accountDescription != NULL) { 

if (somThis->accountDescription != NULL) SOMFree(somThis->accountDescription) ; 
somThis->accountDescription = (string) SOMMal loc(strlen (accountDescri pti on)+l) ; 
strcpy (somThis->accountDescri pti on, accountDescri pti on) ; 

} 

else { 

// should raise exception here 

} 


S0M_Scope void SOMLINK retrieve(SOMAccount *somSelf, Environment *ev) 

{ 

SOMAccountData *somThis = SOMAccountGetData(somSelf) ; 
SOMAccountMethodDebug("SOMAccount"," retrieve") ; 

DaxAcct DAXAccountObject; 

// retrieve a customer from database with the customer id 
try { 

DAXAccountObject. setAcct_id( somThi s->accountNumber ); 
DAXAccountObject. retrieve() ; 

} catch (IException &exc) { 
somPrintf ("Error id: %d\n", exc.errorldO ); 
for (unsigned long i = 0; i < exc.textCount() ; i++) 
somPrintf ("Error Text: %s\n", exc.text(i) ); 
somPrintf ("Error Class: %s\n",exc.name() ); 
somSelf->_set_balance(ev,0.0) ; 
somSel f->_set_branchld (ev ," ") ; 
somSel f->_set_accountDescri pti on (ev ," ") ; 
return; 

} 

somSel f->_set_bal ance (ev , DAXAccountObject . acct_bal ance () ) ; 

somSel f->_set_branchld (ev, DAXAccountObject . acct_bri d() ) ; 

somSel f->_set_accountDescri pti on (ev , DAXAccountObj ect . acct_type () ) ; 


S0M_Scope void SOMLINK update(SOMAccount *somSelf, Environment *ev) 

{ 

SOMAccountData *somThis = SOMAccountGetData (somSel f) ; 
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SOMAccountMethodDebug ("SOMAccount"," update") ; 

DaxAcct DAXAccountObject; 

// update the customer with the current id 
try { 

DAXAccountObject. setAcct_id (somThi s->accountNumber ); 

DAXAccountObject.setAcct_balance (somThi s->bal ance ); 

DAXAccountObject. setAcct_brid (somThi s->branchld ); 

DAXAccountObject. setAcct_type (somThi s->accountDescription) ; 

DAXAccountObject. update() ; 

DSObject.commit() ; 

} catch (IException &exc) { 
somPrintf ("Error id: %d\n", exc.errorldO ); 
for (unsigned long i = 0; i < exc.textCount() ; i++) 
somPrintf ("Error Text: %s\n", exc.text(i) ); 
somPrintf ("Error Class: %s\n", exc.name() ); 

} 


S0M_Scope void SOMLINK add (SOMAccount *somSelf, Environment *ev) 

{ 

SOMAccountData *somThis = SOMAccountGetData(somSelf) ; 
SOMAccountMethodDebug ("SOMAccount", "add") ; 

DaxAcct DAXAccountObject; 

try { 

DAXAccountObject. setAcct_id (somThi s->accountNumber ); 

DAXAccountObject.setAcct_balance (somThi s->bal ance ); 
DAXAccountObject.setAcct_brid (somThi s->branchld ); 

DAXAccountObject.setAcct_type (somThi s->accountDescri pti on ); 

DAXAccountObject. add ( ) ; 

DSObject.commitO ; 

} catch (IException &exc) { 
somPrintf ("Error id: %d\n", exc.errorldO ); 
for (unsigned long i = 0; i < exc.textCount() ; i++) 
somPrintf ("Error Text: %s\n", exc.text(i) ); 
somPrintf ("Error Class: %s\n",exc.name() ); 

} 


S0M_Scope void SOMLINK del (SOMAccount *somSelf, Environment *ev) 

{ 

SOMAccountData *somThis = SOMAccountGetData(somSelf) ; 
SOMAccountMethodDebug ("SOMAccount", "del") ; 

DaxAcct DAXAccountObject; 

try { 

DAXAccountObject. setAcct_id ( somThi s->accountNumber ); 
DAXAccountObject. del () ; 

DSObject.commitO ; 

} catch (IException &exc) { 
somPrintf ("Error id: %d\n", exc.errorldO ); 
for (unsigned long i = 0; i < exc.textCount() ; i++) 
somPrintf ("Error Text: %s\n", exc.text(i) ); 
somPrintf ("Error Class: %s\n",exc.name() ); 

} 


S0M_Scope void SOMLINK somDestruct (SOMAccount *somSelf, octet doFree, 

somDestructCtrl* Ctrl) 
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{ 

SOMAccountData *somThis; /* set in BeginDestructor */ 
somDestructCtrl global Ctrl; 
somBool eanVector myMask; 

SOMAccountMethodDebug("SOMAccount","somDestruct") ; 

SOMAccount_Begi nDestructor; 

/* 

* local SOMAccount deinitialization code added by programmer 
*/ 

SOMAccount_EndDestructor; 

somPrintf ("%d is destructed\n", somSelf); 

} 

S0M_Scope void SOMLINK somDefaultlnit (SOMAccount *somSelf, somlnitCtrl* Ctrl) 

{ 

SOMAccountData *somThis; /* set in Beginlnitial izer */ 
somlnitCtrl gl obal Ctrl ; 
somBool eanVector myMask; 

SOMAccountMethodDebug("SOMAccount","somDefaul tlni t") ; 

SOMAccount_Begin Initial izer_somDefaul tlni t; 

SOMAccount_Ini t_SOMObject_somDefaul tlni t (somSel f , Ctrl ) ; 

/* 

* local SOMAccount initialization code added by programmer 
*/ 

somPrintf ("%d is initialized and active from now on...\n", somSelf); 


SOMEXTERN void SOMLINK SOMInitModule( long majorVersion, 

long minorVersion, 
string className) 


SOMAccountNewClass (0,0) ; 

/* 

* local dTstCust initialization code added by programmer 
*/ 

try { 

DSObject .connect ("CS00DB", "FCE", "PASSWORD") ; 

} catch (IException &exc) { 
somPrintf("Failed: Exception occurs\n"); 
somPrintf ("Error id: %ld\n", exc.errorldO) ; 
for (unsigned long i = 0; i < exc.textCount() ; i++) 
somPrintf ("Error Text: %s\n", exc.text(i) ); 
somPrintf ("Error Class: %s\n". exc.nameO); 

} 

somPri ntf ^ ,, *************************\p ,/ ^ • 


somPrintf ("* SOM ACCOUNT SERVER *\n") 

somPrintf ("* initialized *\n") 

somPrintf("* and connected to *\n") 

somPrintf("* CS00DB *\n") 

somPrintf("* *\n") 

somPrintf("* waiting for client *\n") 

somPrintf("* connection now *\n") 

somPrintf("* *\n") 


somPri ntf ^ ,, *************************\p\p ,/ ^ • 

} 
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E.2 SOM Bank Implementation 


/* 

* This file was generated by the SOM Compiler. 

* Generated using: 

* SOM incremental update: 2.42 
*/ 

/* 

* This file was generated by the SOM Compiler and Emitter Framework. 

* Generated using: 

* SOM Emitter emitxtm: 2.42 
*/ 

#i fndef S0M_Modul e_sombank_Source 
#def i ne S0M_Modul e_sombank_Source 
#endi f 

#define SOMBank_Cl ass_Source 

#def i ne SOMMSi ngl el nstance_Cl ass_Source 

#include "SOMBank.xih" 


/* 

*Method from the IDL attribute statement: 

*"attribute string name" 

*/ 

/* 

* attribute sequencer ong> customerldList; 

* attribute sequence<string> accountldList; 

* attribute sequence<string> branchldLi st; 

* attribute sequence<string> currencyldList; 

*/ 

S0M_Scope string SOMLINK _get_name(SOMBank *somSelf, Environment *ev) 

{ 

SOMBankData *somThis = SOMBankGetData(somSel f) ; 
SOMBankMethodDebug("SOMBank","_get_name") ; 

// just in case. . . 
if (somThi s->name == NULL) { 

somThi s->name = (string) SOMMal 1 oc (2) ; 
strcpy(somThis->name," "); 

} 

string name = (string) SOMMal loc(strlen (somThi s->name)+l) ; 
strcpy(name, somThi s->name) ; 
return name; 


/* 

*Method from the IDL attribute statement: 

*"attribute string name" 

*/ 

/* 

* attribute sequencer ong> customerldList; 

* attribute sequence<string> accountldList; 

* attribute sequence<string> branchldLi st; 

* attribute sequence<string> currencyldList; 
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*/ 

SOM_Scope void SOMLINK _set_name(SOMBank *somSelf, Environment *ev, 

string name) 

{ 

SOMBankData *somThis = SOMBankGetData(somSel f) ; 

SOMBankMethodDebug ("SOMBank", "_set_name") ; 

if (name!=NULL) { 

if (somThis->name != NULL) SOMFree(somThi s->name) ; 
somThi s->name = (string) SOMMal 1 oc(strl en(name)+l) ; 
strcpy(somThis->name, name); 



S0M_Scope _IDL_SEQUENCE_SOMCustomer SOMLINK customers (SOMBank *somSelf, 

Environment *ev) 

{ 

SOMBankData *somThis = SOMBankGetData(somSel f) ; 

SOMBankMethodDebug ("SOMBank", "customers") ; 

// customer list to be returned 
_IDL_SEQUENCE_SOMCustomer customerLi st; 

// the data access customer object, used to access the actual 
// DB2/2 database, in a 00 way. IT is generated by DAX of VA C++ V3 
DaxCust *cursorCustomer; 

IVSequence<DaxCust *>: :Cursor cursor(*(DAXCustMgrObject.items())) ; 

// number of total customers 
int numElements; 

// a refresh takes a whole new list of customers 
DAXCustMgrObject.refresh() ; 

numElements = DAXCustMgrObject.i tems() ->numberOfEl ements() ; 

// now prepare the customerLi st for inserting element 
sequenceMaximum(customerList) = numElements; 

customerLi st._buffer = (SOMCustomer **)S0MMal loc(sizeof (SOMCustomer *) * numElements); 
sequenceLength (customerLi st) = 0; 

// the actual logic of inserting found customer into the return list 
for (cursor. setToFirst() ; cursor. i sVal id() ; cursor. setToNextO) { 
cursorCustomer = DAXCustMgrObject. i terns ()->elementAt (cursor) ; 

// looks complicated here, but just setting each attribe on 

// the list of return customer, based on what found from the database 

// access object. 

sequenceEl ement (customerLi st, sequenceLength (customerLi st)) - new S0MCustomer() ; 

sequenceEl ement (customerLi st , sequenceLength (customerLi st) ) ->_set_customerId(ev, cursorCustomer->cust_i d () ) ; 
sequenceEl ement (customerLi st , sequenceLength (customerLi st) ) ->_set_accountId (ev, cursorCustomer->cust_aci d() ) ; 
sequenceEl ement (customerLi st , sequenceLength (customerLi st) ) ->_set_f i rstName (ev , cursorCustomer->cust_f name () ) ; 
sequenceEl ement (customerLi st, sequenceLength (customerLi st) )->_set_lastName(ev, cursorCustomer->cust_l name()) ; 
sequenceEl ement (customerLi st , sequenceLength (customerLi st) ) ->_set_street (ev , cursorCustomer->cust_street () ) ; 
sequenceEl ement (customerLi st, sequenceLength (customerLi st) )->_set_ci ty (ev, cursorCustomer->cust_ci ty () ) ; 
sequenceEl ement (customerLi st, sequenceLength (customerLi st))->_set_state(ev, cursorCustomer->cust_state()) ; 
sequenceEl ement (customerLi st , sequenceLength (customerLi st) ) ->_set_zi p (ev , cursorCustomer->cust_zi p () ) ; 
sequenceEl ement (customerLi st, sequenceLength (customerLi st))->_set_homePhone(ev, cursorCustomer->cust_hphone()) ; 
sequenceEl ement (customerLi st, sequenceLength (customerLi st))->_set_workPhone(ev, cursorCustomer->cust_wphone()) ; 

++sequenceLength (customerLi st) ; 

} 

// return the list 
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return (customerLi st) ; 


S0M_Scope _IDL_SEQUENCE_SOMCurrency SOMLINK currencies (SOMBank *somSelf, 

Environment *ev) 

{ 

SOMBankData *somThis = SOMBankGetData(somSel f) ; 

SOMBan kMethodDebug ("SOMBank"," currenci es" ) ; 

// currency list to be returned 
_IDL_SEQUENCE_SOMCurrency currencyLi st; 

// the data access currency object, used to access the actual 
// DB2/2 database, in a 00 way. IT is generated by DAX of VA C++ V3 
DaxCury *cursorCurrency; 

IVSequence<DaxCury *>: :Cursor cursor(*(DAXCuryMgrObject.items())) ; 

// number of total currency 
int numElements; 

// a refresh takes a whole new list of currencies 
DAXCuryMgrObject.refresh() ; 

numElements = DAXCuryMgrObject.i tems() ->numberOfEl ements() ; 


// now prepare the currencyLi st for inserting element 
sequenceMaximum(currencyList) = numElements; 

currencyList._buffer = (SOMCurrency **) SOMMal loc(sizeof (SOMCurrency *) * numElements); 
sequenceLength (currencyLi st) = 0; 

// the actual logic of inserting found customer into the return list 
for (cursor. setToFirst() ; cursor. i sVal id() ; cursor. setToNextO) { 
cursorCurrency = DAXCuryMgrObject . i terns ()->elementAt (cursor) ; 
sequenceElement(currencyLi st, sequenceLength (currencyLi st)) = new SOMCurrencyO ; 

// looks complicated here, but just setting each attribe on 

// the list of return currency, based on what found from the database 

// access object. 

sequenceEl ement (currency Li st , sequenceLength (currencyLi st) ) ->_set_currency Id (ev , cursorCurrency->curr_i d () ) ; 
sequenceEl ement (currencyLi st, sequenceLength (currencyLi st) )->_set_name(ev,cursorCurrency->curr_name()) ; 
sequenceEl ement (currencyLi st, sequenceLength (currency Li st))->_set_country(ev,cursorCurrency->curr_cnty()) ; 
sequenceEl ement (currencyLi st, sequenceLength (currencyLi st) ) ->_set_xRateBuy (ev,cursorCurrency->curr_xrate_buy () ) ; 
sequenceEl ement (currencyLi st, sequenceLength (currencyLi st) )->_set_xRateSel 1 (ev,cursorCurrency->curr_xrate_sel 1 ()) ; 
sequenceEl ement (currencyLi st, sequenceLength (currencyLi st) )->_set_forgInfo(ev,cursorCurrency->curr_forg_i nfo() ) ; 
sequenceEl ement (currency Li st , sequenceLength (currencyLi st) ) ->_set_descri pti on (ev , cursorCurrency->curr_desc () ) ; 

++sequenceLength (currencyLi st) ; 

} 

// return the list 
return (currencyLi st) ; 

} 

S0M_Scope _IDL_SEQUENCE_SOMBranch SOMLINK SMBranches (SOMBank *somSelf, 

Environment *ev) 

{ 

SOMBankData *somThis = SOMBankGetData(somSel f) ; 

SOMBan kMethodDebug ("SOMBan k"," SMBranches" ) ; 

// branches list to be returned 
_IDL_SEQUENCE_SOMBranch branchList; 

// the data access branch object, used to access the actual 
// DB2/2 database, in a 00 way. IT is generated by DAX of VA C++ V 3 
DaxBrch *cursorBranch; 

IVSequence<DaxBrch *>: :Cursor cursor(*(DAXBrchMgrObject.i terns ())) ; 
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// total number of branches 
int numElements; 

// a refresh takes a whole new list of branches 
DAXBrchMgrObject.refresh() ; 

numElements = DAXBrchMgrObject.i tems() ->numberOfEl ements() ; 


// now prepare the branchList for inserting element 
sequenceMaximum(branchLi st) = numElements; 

branchList. _buffer = (SOMBranch **)S0MMal 1 oc(sizeof (SOMBranch *) * numElements); 
sequenceLength (branchList) = 0; 

// the actual logic of inserting found customer into the return list 
for (cursor. setToFirst() ; cursor. i sVal id() ; cursor. setToNext()) { 
cursorBranch = DAXBrchMgrObject.items()->elementAt(cursor) ; 
sequenceElement(branchLi st, sequenceLength (branchList)) = new S0MBranch(); 

// looks complicated here, but just setting each attribe on 

// the list of return customer, based on what found from the database 

// access object. 

sequenceEl ement (branch Li st , sequenceLength (branch Li st) ) ->_set_branchld (ev,cursorBranch->brch_i d () ) ; 
sequenceEl ement (branch Li st, sequenceLength (branch Li st) )->_set_name(ev,cursorBranch->brch_name() ) ; 
sequenceEl ement (branch Li st , sequenceLength (branch Li st) ) ->_set_street (ev,cursorBranch->brch_street () ) ; 
sequenceEl ement (branch Li st , sequenceLength (branch Li st) ) ->_set_ci ty (ev,cursorBranch->brch_ci ty () ) ; 
sequenceEl ement (branch Li st, sequenceLength (branch Li st) )->_set_state(ev,cursorBranch->brch_state()) ; 
sequenceEl ement (branch Li st , sequenceLength (branch Li st) ) ->_set_zi p(ev,cursorBranch->brch_zi p () ) ; 
++sequenceLength (branchList) ; 


// return the list 
return (branchList); 


S0M_Scope _IDL_SEQUENCE_SOMBranch SOMLINK SMbranches (SOMBank *somSelf, 

Environment *ev) 

{ 

SOMBankData *somThis = SOMBankGetData(somSel f) ; 

SOMBankMethodDebug ("SOMBan k"," SMbranches" ) ; 

/* Return statement to be customized: */ 

{ _IDL_SEQUENCE_SOMBranch retVal ; return (retVal); } 


S0M_Scope _IDL_SEQUENCE_SOMAccount SOMLINK accounts (SOMBank *somSelf, 

Environment *ev) 

{ 

SOMBankData *somThis = SOMBankGetData(somSel f) ; 

SOMBankMethodDebug ("SOMBank", "accounts") ; 

// account list to be returned 
_IDL_SEQUENCE_SOMAccount accountLi st; 

// the data access account object, used to access the actual 
// DB2/2 database, in a 00 way. IT is generated by DAX of VA C++ V 3 
DaxAcct *cursorAccount; 

IVSequence<DaxAcct *>: : Cursor cursor (*(DAXAcctMgrObject. items ()) ) ; 

// number of total accounts 
int numElements; 

// a refresh takes a whole new list of accounts 
DAXAcctMgrObject.refresh() ; 
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numElements = DAXAcctMgrObject.i tems() ->numberOfEl ements() ; 

// now prepare the accountList for inserting element 
sequenceMaximum(accountLi st) = numElements; 

accountLi st._buffer = (SOMAccount **)SOMMalloc(sizeof(SOMAccount *) * numElements); 
sequenceLength(accountList) = 0; 

// the actual logic of inserting found customer into the return list 
for (cursor. setToFirst() ; cursor. i sVal id() ; cursor. setToNextO) { 

cursorAccount = DAXAcctMgrObject .items ()->elementAt (cursor) ; 

// looks complicated here, but just setting each attribe on 

// the list of return account, based on what found from the database 

// access object. 

sequenceEl ement(accountl_i st, sequenceLength (accountList)) = new S0MAccount() ; 
sequenceEl ement (accountLi st , sequenceLength (accountLi st) ) ->_set_account Number (ev, 
cursorAccount->acct_id() ) ; 

sequenceEl ement (accountLi st , sequenceLength (accountLi st) ) ->_set_bal ance(ev, 
cursorAccount->acct_bal ance() ) ; 

sequenceEl ement (accountLi st , sequenceLength (accountLi st) ) ->_set_branchld(ev, 
cursorAccount->acct_brid()) ; 

sequenceEl ement (account Li st , sequenceLength (accountLi st) ) ->_set_accountDescri pti on (ev , 
cursorAccount->acct_type()) ; 

++sequenceLength (accountLi st) ; 

} 


// return the list 
return (accountList); 


/* 

* S0M_Scope _IDL_SEQUENCE_long 

* 

*/ 


SOMLINK al lCustomerlds (SOMBank *somSelf, 
Environment *ev) 


/* 

* The prototype for al lCustomerlds was replaced by the following prototype: 

*/ 

S0M_Scope _IDL_SEQUENCE_1 ong SOMLINK al 1 CustomerIds(SOMBank *somSelf, Environment *ev) 

{ 

SOMBankData *somThis = SOMBankGetData(somSel f) ; 

SOMBankMethodDebug("SOMBank","al lCustomerlds") ; 

// list of all customer ids to be returned 
_IDL_SEQUENCE_long matchCustomerlds; 

// total number of customers 
int numElements; 


// refresh to get the new total list 
DAXCustMgrObject.refresh() ; 

// prepare to construct the list 

numElements = DAXCustMgrObject.i tems() ->numberOfEl ements() ; 
sequenceMaximum(matchCustomerlds) = numElements; 
matchCustomerlds. _buffer = 

(long *)S0MMal loc(sizeof (1 ong *) * numElements); 

// actual logic of list insertion 
sequenceLength(matchCustomerlds) = 0; 
for (int counter=l; counter<=numElements; counter++) { 
sequenceEl ement (mat chCustomer Ids, counter- 1) = 

DAXCustMgrObject . i terns () ->el ementAtPosi ti on (IPosi ti on (counter) ) ->cust_i d () ; 
++sequenceLength (matchCustomerlds) ; 

} /* endfor */ 

// return the list 
return matchCustomerlds; 
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/* 

* The prototype for al 1 Accountlds was replaced by the following prototype: 

*/ 

S0M_Scope _IDL_SEQUENCE_stri ng SOMLINK al lAccountIds(SOMBank *somSelf, Environment *ev) 

{ 

SOMBankData *somThis = SOMBankGetData(somSel f) ; 

SOMBankMethodDebug("SOMBank","al 1 Accountlds") ; 

// list of all account ids to be returned 
_IDL_SEQUENCE_string matchAccountlds; 

// total number of accounts 
int numElements; 

// refresh to get the new total list 

DAXAcctMgrObject. refresh () ; 

// prepare to construct the list 

numElements = DAXAcctMgrObject. i tems() ->numberOfEl ements() ; 
sequenceMaximum(matchAccountlds) = numElements; 
matchAccountlds. _buffer = 

(string *)SOMMalloc(sizeof(string *) * numElements); 
sequenceLength (matchAccountlds) = 0; 

// actual logic of list insertion 

for (int counter=l; counter<=numElements; counter++) { 

sequenceEl ement (mat chAccount Ids, counter- 1) = 

(stri ng) SOMMal loc(strl en(DAXAcctMgrObject.i terns () ->el ementAtPosi ti on (I Position (counter) )->acct_id())+l) ; 

strcpy (sequenceEl ement (matchAccountIds,counter-l) , 

DAXAcctMgrObject . i terns ()->el ementAtPosi ti on (I Posi ti on (counter) )->acct_id() ) ; 

++sequenceLength (matchAccountlds) ; 

} /* endfor */ 

// return the list 
return matchAccountlds; 


/* 

* The prototype for allBranchlds was replaced by the following prototype: 

*/ 

S0M_Scope _IDL_SEQUENCE_string SOMLINK al 1 Branchlds (SOMBank *somSelf, Environment *ev) 

{ 

SOMBankData *somThis = SOMBankGetData(somSel f) ; 

SOMBankMethodDebug("SOMBank","al 1 Branchlds") ; 

// list of all branch ids to be returned 
_IDL_SEQUENCE_string matchBranchlds; 

// total number of branches 
int numElements; 

// refresh to get the new total list 
DAXBrchMgrObject.refresh() ; 

// prepare to construct the list 

numElements = DAXBrchMgrObject.i tems() ->numberOfEl ements() ; 
sequenceMaximum(matchBranchlds) = numElements; 
matchBranchlds. _buffer = 

(string *)SOMMalloc(sizeof(string *) * numElements); 
sequenceLength (matchBranchlds) = 0; 
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// actual logic of list insertion 

for (int counter=l; counter<=numElements; counter++) { 

sequenceEl ement (mat chBranch Ids, coun ter- 1) = 

(string) SOMMal loc(strlen(DAXBrchMgrObject. items ()->elementAtPosi ti on (I Position (counter) )->brch_id())+l) ; 

strcpy (sequenceEl ement (matchBranchIds,counter-l) , 

DAXBrchMgrObject . i terns ()->elementAtPosi tion(IPosi ti on (counter) )->brch_id() ) ; 

++sequencel_ength(matchBranchIds) ; 

} /* endfor */ 

return matchBranchlds; 


/* 

* S0M_Scope _IDL_SEQUENCE_string 

* 

*/ 


SOMLINK al 1 Currencylds (SOMBank *somSelf, 
Environment *ev) 


S0M_Scope _IDL_SEQUENCE_string SOMLINK al 1 Currencylds (SOMBank *somSelf, Environment *ev) 

{ 

SOMBankData *somThis = SOMBankGetData(somSel f) ; 

SOMBankMethodDebug("SOMBank","al 1 Currency Ids") ; 

// list of all currency Ids to be returned 
_IDL_SEQUENCE_string matchCurrencylds; 

// total number of branches 
int numElements; 

// refresh to get the new total list 
DAXCuryMgrObject.refresh() ; 

// prepare to construct the list 

numElements = DAXCuryMgrObject.i tems() ->numberOfEl ements() ; 
sequenceMaximum(matchCurrencylds) = numElements; 
matchCurrencylds. _buffer = 

(string *)SOMMalloc(sizeof(string *) * numElements); 
sequenceLength(matchCurrencylds) = 0; 

// actual logic of list insertion 

for (int counter=l; counter<=numElements; counter++) { 

sequenceEl ement (mat chCurrency Ids, counter- 1) = 

(string) SOMMal loc(strlen(DAXCuryMgrObject. items ()->elementAtPosi ti on (I Position (counter) )->curr_id())+l) ; 

strcpy (sequenceEl ement (matchCurrencyIds,counter-l) , 

DAXCuryMgrObject . i terns () ->el ementAtPosi ti on ( I Posi ti on (counter) ) ->curr_i d () ) ; 

++sequenceLength (matchCurrencylds) ; 

} /* endfor */ 

return matchCurrencylds; 

} 


/* 

* This is put in here to accept a SQL statement 

* (as the clause) and with the clause we can ask the corresponding 

* data access manager object to retrieve a list of objects which satisfy 

* the SQL statement. Dynamic SQL statement is used. 

* Note: this function is not implemented yet. The TOTAL list of objects 

* will be returned, and the clause simply get ignored. 
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* For how to use the data access manager object for the dynamic SQL search 

* please refer to the generated DAX program stubs 
*/ 

S0M_Scope _IDL_SEQUENCE_long SOMLINK matchingCustomerIds(SOMBank *somSelf, 

Environment *ev, 
string clause) 

{ 

SOMBankData *somThis = SOMBankGetData(somSel f) ; 

SOMBan kMet hodDebug ("SOMBan k", "match i ngCustomerlds") ; 

/* Return statement to be customized: */ 

_IDL_SEQUENCE_long matchCustomerlds; 

DAXCustMgrObject.refresh() ; 

int numElements = DAXCustMgrObject.i tems() ->numberOfEl ements() ; 

sequenceMaximum(matchCustomerlds) = numElements; 
matchCustomerlds ._buffer = 

(long *)SOMMalloc(sizeof(long *) * numElements); 

sequenceLength(matchCustomerlds) = 0; 
for (int counter=l; counter<=numElements; counter++) { 
sequenceEl ement (mat chCustomer Ids, counter- 1) = 

DAXCustMgrObject . i terns () ->el ementAtPosi ti on (IPosi ti on (counter) ) ->cust_i d () ; 
++sequenceLength (matchCustomerlds) ; 

} /* endfor */ 

return matchCustomerlds; 

} 


/* 

* This is put in here to accept a SQL statement 

* (as the clause) and with the clause we can ask the corresponding 

* data access manager object to retrieve a list of objects which satisfy 

* the SQL statement. Dynamic SQL statement is used. 

* Note: this function is not implemented yet. The TOTAL list of objects 

* will be returned, and the clause simply get ignored. 

* For how to use the data access manager object for the dynamic SQL search 

* please refer to the generated DAX program stubs 
*/ 

S0M_Scope _IDL_SEQUENCE_string SOMLINK matchingAccountIds(SOMBank *somSelf, 

Environment *ev, 
string clause) 

{ 

SOMBankData *somThis = SOMBankGetData(somSel f) ; 

SOMBan kMet hodDebug ("SOMBan k", "match i ngAccountlds") ; 

_IDL_SEQUENCE_string matchAccountlds; 
int numElements; 

DAXAcctMgrObject.refresh() ; 

numElements = DAXAcctMgrObject.i terns () ->numberOfEl ements() ; 
sequenceMaximum(matchAccountlds) = numElements; 
matchAccountlds. _buffer = 

(string *)SOMMalloc(sizeof(string *) * numElements); 
sequenceLength (matchAccountlds) = 0; 

for (int counter=l; counter<=numElements; counter++) { 
sequenceEl ement (mat chAccount Ids, counter- 1) = 

(string) SOMMal loc(strlen(DAXAcctMgrObject . items ()->el ementAtPosi ti on (I Position (counter) )->acct_id())+l) ; 
strcpy (sequenceEl ement (matchAccountIds,counter-l) , 

DAXAcctMgrObject . i terns ()->el ementAtPosi ti on (IPosi ti on (counter) )->acct_id() ) ; 

++sequenceLength (matchAccountlds) ; 
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} /* endfor */ 
return matchAccountlds; 


} 


/* 

* This is put in here to accept a SQL statement 

* (as the clause) and with the clause we can ask the corresponding 

* data access manager object to retrieve a list of objects which satisfy 

* the SQL statement. Dynamic SQL statement is used. 

* Note: this function is not implemented yet. The TOTAL list of objects 

* will be returned, and the clause simply get ignored. 

* For how to use the data access manager object for the dynamic SQL search 

* please refer to the generated DAX program stubs 
*/ 

S0M_Scope _IDL_SEQUENCE_string SOMLINK matchingBranchIds(SOMBank *somSelf, 

Environment *ev, 
string clause) 

{ 

SOMBankData *somThis = SOMBankGetData(somSel f) ; 

SOMBan kMet hodDebug("SOMBank", "match i ngBranchlds") ; 

_IDL_SEQUENCE_string matchBranchlds; 
int numElements; 

DAXBrchMgrObject.refresh() ; 

numElements = DAXBrchMgrObject.i tems() ->numberOfEl ements() ; 
sequenceMaximum(matchBranchlds) = numElements; 
matchBranchlds. _buffer = 

(string *)SOMMalloc(sizeof(string *) * numElements); 
sequenceLength (matchBranchlds) = 0; 

for (int counter=l; counter<=numElements; counter++) { 
sequenceEl ement (matchBranchIds,counter-l) = 

(string) SOMMal loc(strlen(DAXBrchMgrObject . items ()->elementAtPosi ti on (I Position (counter) )->brch_id())+l) ; 
strcpy (sequenceEl ement (matchBranchIds,counter-l) , 

DAXBrchMgrObject . i terns ()->elementAtPosi tion(IPosi ti on (counter) )->brch_id() ) ; 

++sequenceLength (matchBranchlds) ; 

} /* endfor */ 

return matchBranchlds; 

} 


/* 

* This is put in here to accept a SQL statement 

* (as the clause) and with the clause we can ask the corresponding 

* data access manager object to retrieve a list of objects which satisfy 

* the SQL statement. Dynamic SQL statement is used. 

* Note: this function is not implemented yet. The TOTAL list of objects 

* will be returned, and the clause simply get ignored. 

* For how to use the data access manager object for the dynamic SQL search 

* please refer to the generated DAX program stubs 
*/ 

/* 

* SOM specific details 
*/ 

S0M_Scope _IDL_SEQUENCE_string SOMLINK matchingCurrencyIds(SOMBank *somSelf, 

Environment *ev, 
string clause) 
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{ 

SOMBankData *somThis = SOMBankGetData(somSel f) ; 

SOMBan kMethodDebug ("SOMBank", "matchi ngCurrencylds") ; 

_IDL_SEQUENCE_string matchCurrencylds; 
int numElements; 

DAXCuryMgrObject.refresh() ; 

numElements = DAXCuryMgrObject.i tems() ->numberOfEl ements() ; 
sequenceMaximum(matchCurrencylds) = numElements; 
matchCurrencyIds._buffer = 

(string *)SOMMalloc(sizeof(string *) * numElements); 
sequenceLength(matchCurrencylds) = 0; 

for (int counter=l; counter<=numElements; counter++) { 
sequenceEl ement (mat chCurrency Ids, counter- 1) = 

(string) SOMMal loc(strlen(DAXCuryMgrObject. items ()->elementAtPosi ti on (I Position (counter) )->curr_id())+l) ; 
strcpy (sequenceEl ement (matchCurrencyIds,counter-l) , 

DAXCuryMgrObject . i terns ()->elementAtPosi t i on ( I Posi ti on (counter) ) ->curr_id() ) ; 

++sequenceLength (matchCurrencylds) ; 

} /* endfor */ 

return matchCurrencylds; 


S0M_Scope void SOMLINK somDestruct (SOMBank *somSelf, octet doFree, 

somDestructCtrl* Ctrl) 

{ 

SOMBankData *somThis; /* set in BeginDestructor */ 
somDestructCtrl global Ctrl; 
somBooleanVector myMask; 

SOMBankMethodDebug ("SOMBank", " somDestruct" ) ; 

S0MBank_Begi nDestructor; 

/* 

* local SOMBank deinitialization code added by programmer 
*/ 

SOMBank_EndDestructor; 

somPrintf ("%d is destructed\n", somSelf); 


S0M_Scope void SOMLINK somDefaultlnit (SOMBank *somSelf, somlnitCtrl* Ctrl) 

{ 

SOMBankData *somThis; /* set in Beginlnitial izer */ 
somlnitCtrl gl obal Ctrl ; 
somBooleanVector myMask; 

SOMBan kMethodDebug ("SOMBank", "somDefaul 1 1 nit") ; 

SOMBank_BeginIni tial izer_somDefaul tlni t ; 

SOMBan k_I ni t_S0M0bj ect_somDef aul 1 1 n i t (somSel f , Ctrl ) ; 

somThi s->name = (string)SOMMal loc(strlen("ITSC 00 BANK") + 1 ); 
strcpy (somThi s->name, "ITSC 00 BANK"); 

somPrintf ("%d is initialized and active from now on...\n", somSelf); 

} 


SOMEXTERN void SOMLINK SOMInitModule( long majorVersion, 

long minorVersion, 
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string className) 


S0MBankNewClass(0,0) ; 

// connect itself with the CSOODB database 
try { 

DSObject. connect ("CSOODB", "FCE", "PASSWORD"); 

} catch (IException &exc) { 
somPrintf("Failed: Exception occurs\n"); 
somPrintf ("Error id: %ld\n", exc.errorldO ) ; 
for (unsigned long i = 0; i < exc.textCount() ; i++) 
somPrintf ("Error Text: %s\n", exc.text(i) ); 
somPrintf ("Error Class: %s\n", exc.nameO); 

} 


sornPri ntf ^ ,/ *************************\p // 


somPrintf ("* SOM BANK SERVER *\n") 

somPrintf ("* initialized *\n") 

somPrintf("* and connected to *\n") 

somPrintf("* CSOODB *\n") 

somPrintf("* *\n") 

somPrintf("* waiting for client *\n") 

somPrintf("* connection now *\n") 

somPrintf("* *\n") 


sornPri ntf ^ // *************************\p\p ,/ ^ • 

} 


Figure 90 (Part 11 of 11). SOMBank Implementation 


E.3 SOMCurrency Implementation 


/* 

* This file was generated by the SOM Compiler and Emitter Framework. 

* Generated using: 

* SOM Emitter emitxtm: 2.42 
*/ 

#i fndef S0M_Modul e_somcury_Source 
#def i ne S0M_Modul e_somcury_Source 
#endi f 

#define SOMCurrency_Cl ass_Source 

#def i ne SOMMSi ngl eInstance_Cl ass_Source 

#include "SOMCury.xih" 


/* 

*Method from the IDL attribute statement: 
*"attribute string currencyld" 

*/ 


S0M_Scope string SOMLINK _get_currencyld (SOMCurrency *somSelf, 

Environment *ev) 


{ 

SOMCurrencyData *somThis = SOMCurrencyGetData(somSel f) ; 
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SOMCurrencyMethodDebug("SOMCurrency","_get_currencyId") ; 

if (somThi s->currencyld == NULL) { 

somThi s->currencyld = (string) SOMMal 1 oc(l) ; 
strcpy (somThi s->currency Id,""); 

} 

string currencyld = (string) SOMMal loc(strl en(somThi s->currencyld)+l) ; 
strcpy (currencyld, somThi s->currencyld) ; 
return currencyld; 


/* 

*Method from the IDL attribute statement: 

*"attribute string currencyld" 

*/ 

S0M_Scope void SOMLINK _set_currencyId(SOMCurrency *somSelf, 

Environment *ev, string currencyld) 

{ 

SOMCurrencyData *somThis = SOMCurrencyGetData(somSelf) ; 
SOMCurrencyMethodDebug("SOMCurrency","_set_currencyId") ; 

if (somThi s->currencyld != NULL) SOMFree(somThi s->currencyld) ; 
somThi s->currencyld = (string) SOMMalloc(strlen(currencyId)+l) ; 
strcpy (somThi s->currencyld, currencyld) ; 


/* 

*Method from the IDL attribute statement: 

*"attribute string name" 

*/ 

S0M_Scope string SOMLINK _get_name(SOMCurrency *somSelf, Environment *ev) 

{ 

SOMCurrencyData *somThis = SOMCurrencyGetData(somSelf) ; 
SOMCurrencyMethodDebug("SOMCurrency","_get_name") ; 

if (somThi s->name == NULL) { 

somThi s->name = (string) SOMMal loc(l) ; 
strcpy (somThi s->name,"") ; 

} 

string name = (string) SOMMal loc(strlen (somThi s->name)+l) ; 
strcpy (name, somThi s->name) ; 
return name; 


/* 

*Method from the IDL attribute statement: 

*"attribute string name" 

*/ 

S0M_Scope void SOMLINK _set_name(SOMCurrency *somSelf, Environment *ev, 

string name) 

{ 

SOMCurrencyData *somThis = SOMCurrencyGetData(somSelf) ; 
SOMCurrencyMethodDebug("SOMCurrency","_set_name") ; 

if (somThi s->name != NULL) SOMFree(somThis->name) ; 
somThi s->name = (string) SOMMal loc(strlen(name) + l) ; 
strcpy (somThi s->name, name); 
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/* 

*Method from the IDL attribute statement: 

*"attribute string country" 

*/ 

S0M_Scope string SOMLINK _get_country (SOMCurrency *somSelf, 

Environment *ev) 

{ 

SOMCurrencyData *somThis = SOMCurrencyGetData(somSelf) ; 
SOMCurrencyMethodDebug ("SOMCurrency", "_get_country") ; 

if (somThi s->country == NULL) { 

somThi s->country I (string) SOMMal 1 oc(l) ; 
strcpy (somThi s->coun try,"") ; 

} 

string country = (string) SOMMal loc(strlen(somThis->country)+l) ; 
strcpy (country, somThi s->country) ; 
return country; 


/* 

*Method from the IDL attribute statement: 

*"attribute string country" 

*/ 

S0M_Scope void SOMLINK _set_country(SOMCurrency *somSelf, Environment *ev, 

string country) 

{ 

SOMCurrencyData *somThis = SOMCurrencyGetData(somSelf) ; 
SOMCurrencyMethodDebug ("SOMCurrency", "_set_country") ; 

if (somThi s->country != NULL) SOMFree(somThi s->country) ; 
somThi s->country = (string) SOMMal loc(strI en(country)+l) ; 
strcpy (somThi s->country, country) ; 


/* 

*Method from the IDL attribute statement: 

*"attribute string forglnfo" 

*/ 

S0M_Scope string SOMLINK _get_forgInfo(SOMCurrency *somSelf, 

Environment *ev) 

{ 

SOMCurrencyData *somThis = SOMCurrencyGetData(somSelf) ; 
SOMCurrencyMethodDebug("SOMCurrency","_get_forgInfo") ; 

if (somThi s->forgInfo == NULL) { 

somThi s->forgInfo = (string) SOMMal loc(l) ; 
strcpy (somThi s->forg Info,"") ; 

} 

string forglnfo = (string) SOMMal loc(strlen(somThis->forgInfo)+l) ; 
strcpy (forglnfo, somThi s->forgInfo) ; 
return forglnfo; 


/* 

*Method from the IDL attribute statement: 

*"attribute string forglnfo" 

*/ 

S0M_Scope void SOMLINK _set_forgInfo (SOMCurrency *somSelf, Environment *ev. 
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string forglnfo) 


SOMCurrencyData *somThis = SOMCurrencyGetData(somSelf) ; 
SOMCurrencyMethodDebug("SOMCurrency","_set_forgInfo") ; 

if (somThi s->forgInfo ! = NULL) SOMFree(somThis->forgInfo) ; 
somThi s->forgInfo = (string) SOMMalloc(strlen(forgInfo)+l) ; 
strcpy (somThi s->forg!nfo, forglnfo) ; 


/* 

*Method from the IDL attribute statement: 

*"attribute string description" 

*/ 

S0M_Scope string SOMLINK _get_description (SOMCurrency *somSelf, 

Environment *ev) 

{ 

SOMCurrencyData *somThis = SOMCurrencyGetData(somSelf) ; 
SOMCurrencyMethodDebug ("SOMCurrency", "_get_descri pti on") ; 

if (somThi s->description == NULL) { 

somThi s->descri pti on = (string) SOMMal 1 oc(l) ; 
strcpy (somThi s->descri pti on,"") ; 

} 


string description = (string) SOMMal loc(strlen(somThis->description)+l) ; 
strcpy(description, somThi s->descri pti on) ; 
return description; 


/* 

*Method from the IDL attribute statement: 

*"attribute string description" 

*/ 

S0M_Scope void SOMLINK _set_description(SOMCurrency *somSelf, 

Environment *ev, string description) 

{ 

SOMCurrencyData *somThis = SOMCurrencyGetData(somSelf) ; 
SOMCurrencyMethodDebug ("SOMCurrency","_set_descri pti on") ; 

if (somThis->description != NULL) SOMFree(somThis->description) ; 
somThi s->description = (string) SOMMal 1 oc(strl en(description)+l) ; 
strcpy(somThis->description, description) ; 


S0M_Scope void SOMLINK retrieve(SOMCurrency *somSelf, Environment *ev) 

{ 

SOMCurrencyData *somThis = SOMCurrencyGetData(somSelf) ; 
SOMCurrencyMethodDebug ("SOMCurrency"," retrieve") ; 

DaxCury DAXCurrencyObject; 

try { 

DAXCurrencyObject.setCurr_id( somThi s->currency Id ); 
DAXCurrencyObject. retrieve() ; 

} catch (IException &exc) { 
somPrintf ("Error id: %d\n", exc.errorldO ); 
for (unsigned long i = 0; i < exc.textCount() ; i++) 
somPrintf ("Error Text: %s\n", exc.text(i) ); 
somPrintf ("Error Class: %s\n", exc.name() ); 
somSel f->_set_name(ev," "); 
somSel f->_set_country(ev," "); 
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somSel f->_set_xRateBuy (ev," ") ; 
somSel f->_set_xRateSel 1 (ev," ") ; 
somSel f->_set_forgInfo(ev," ") ; 
somSel f->_set_description(ev," ") ; 
return; 

} 

somSel f->_set_name (ev , DAXCurrencyOb j ect . curr_name ( ) ) ; 
somSel f->_set_country (ev , DAXCurrencyObject . curr_cnty () ) ; 
somSel f->_set_xRateBuy (ev , DAXCurrencyOb j ect . curr_xrate_buy () ) ; 
somSel f->_set_xRateSel 1 (ev, DAXCurrencyOb j ect. curr_xrate_sel 1 ()) ; 
somSel f->_set_forgInfo (ev , DAXCurrencyOb j ect . curr_forg_i nfo () ) ; 
somSel f->_set_descri pt i on (ev, DAXCurrencyObject .curr_desc()) ; 


S0M_Scope void SOMLINK update(SOMCurrency *somSelf, Environment *ev) 

{ 

SOMCurrencyData *somThis = SOMCurrencyGetData (somSel f) ; 
SOMCurrencyMethodDebug ("SOMCurrency"," update" ) ; 

DaxCury DAXCurrencyObject; 

try { 

DAXCurrencyObject.setCurr_id ( somThi s->currencyld ); 

DAXCurrencyObject.setCurr_name (IString(somThis->name )); 
DAXCurrencyOb j ect. setCurr_cnty( I String ( somThi s->country )) ; 

DAXCurrencyOb j ect . setCurr_xrate_buy ( IStri ng (somThi s->xRateBuy ) ) ; 

DAXCurrencyOb j ect. setCurr_xrate_sel 1 ( I String ( somThi s->xRateSel 1 ) ) ; 

DAXCurrencyOb j ect. setCurr_forg_i nfo( IStri ng (somThi s->forgInfo )) ; 
DAXCurrencyOb j ect . setCurr_desc (IStri ng (somThi s->descri pti on) ) ; 
DAXCurrencyObject. update() ; 

} catch (IException &exc) { 
somPrintf ("Error id: %d\n", exc.errorldO ); 
for (unsigned long i = 0; i < exc.textCount() ; i++) 
somPrintf ("Error Text: %s\n", exc.text(i) ); 
somPrintf ("Error Class: %s\n",exc.name() ); 

} 


S0M_Scope void SOMLINK add (SOMCurrency *somSelf, Environment *ev) 

{ 

SOMCurrencyData *somThis = SOMCurrencyGetData (somSel f) ; 
SOMCurrencyMethodDebug ("SOMCurrency", "add") ; 

DaxCury DAXCurrencyObject; 

try { 

DAXCurrencyObject.setCurr_id ( somThi s->currencyld ); 

DAXCurrencyObject.setCurr_name (IString(somThis->name )); 
DAXCurrencyOb j ect. setCurr_cnty( I String ( somThi s->country ) ) ; 

DAXCurrencyObj ect . setCurr_xrate_buy (IStri ng (somThi s->xRateBuy ) ) ; 

DAXCurrencyObject.setCurr_xrate_sel 1 (I String (somThi s->xRateSel 1 ) ) ; 

DAXCurrencyObj ect. setCurr_forg_info( IStri ng (somThi s->forgInfo )) ; 
DAXCurrencyObject.setCurr_desc (IStri ng (somThi s->description)) ; 
DAXCurrencyObject. add ( ) ; 

} catch (IException &exc) { 
somPrintf ("Error id: %d\n", exc.errorldO ); 
for (unsigned long i = 0; i < exc.textCount() ; i++) 
somPrintf ("Error Text: %s\n", exc.text(i) ); 
somPrintf ("Error Class: %s\n",exc.name() ); 

} 
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SOM_Scope void SOMLINK del (SOMCurrency *somSelf, Environment *ev) 

{ 

SOMCurrencyData *somThis = SOMCurrencyGetData(somSelf) ; 
SOMCurrencyMethodDebug ("SOMCurrency", "del ") ; 

DaxCury DAXCurrencyObject; 

try { 

DAXCurrencyObject.setCurr_id ( somThi s->currencyld ); 

DAXCurrencyObject. del () ; 

} catch (IException &exc) { 
somPrintf ("Error id: %d\n", exc.errorldO ); 
for (unsigned long i = 0; i < exc.textCount() ; i++) 
somPrintf ("Error Text: %s\n", exc.text(i) ); 
somPrintf ("Error Class: %s\n", exc.name() ); 

} 


S0M_Scope void SOMLINK somDestruct (SOMCurrency *somSelf, octet doFree, 

somDestructCtrl* Ctrl) 

{ 

SOMCurrencyData *somThis; /* set in Begi nDestructor */ 
somDestructCtrl global Ctrl; 
somBool eanVector myMask; 

SOMCurrencyMethodDebug ("SOMCurrency", "somDestruct") ; 
SOMCurrency_Begi nDestructor; 

/* 

* local SOMCurrency deinitialization code added by programmer 
*/ 

SOMCurrency_EndDestructor; 

} 


S0M_Scope void SOMLINK somDefaul tlni t (SOMCurrency *somSelf, somlnitCtrl* Ctrl) 

{ 

SOMCurrencyData *somThis; /* set in Begi nlnitial izer */ 
somlnitCtrl global Ctrl; 
somBool eanVector myMask; 

SOMCurrencyMet hodDebug ("SOMCurrency", "somDefaul tlni t") : 
SOMCurrency_BeginIni tial izer_somDefaul tlni t; 

SOMCurrency_Ini t_S0M0bject_somDefaul tlni t (somSel f , Ctrl ) ; 

/* 

* local SOMCurrency initialization code added by programmer 
*/ 


SOMEXTERN void SOMLINK S0MInitModule( long majorVersion, 

long minorVersion, 
string className) 


S0MCurrencyNewClass(0,0) ; 

/* 

* local dTstCust initialization code added by programmer 
*/ 

try { 

DSObject. connect ("CS00DB", "FCE", "PASSWORD"); 

} catch (IException &exc) { 
somPrintf("Failed: Exception occurs\n"); 
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somPri ntf ("Error id: %ld\n", exc.errorldO) ; 
for (unsigned long i = 0; i < exc.textCount() ; i++) 
somPrintf ("Error Text: %s\n", exc.text(i) ); 
somPri ntf ("Error Class: %s\n", exc.nameO); 

} 


Figure 91 (Part 7 of 7). SOMCurrency Implementation 


E.4 SOMCustomer Implementation 


/* 

* This file was generated by the SOM Compiler. 

* Generated using: 

* SOM incremental update: 2.42 
*/ 


/* 

* This file was generated by the SOM Compiler and Emitter Framework. 

* Generated using: 

* SOM Emitter emitxtm: 2.42 
*/ 

/* 

* 

* This file was modified by Raymond Chu for implementation of 

* SOMCustomer object discussed in the red book : GG24XXXX 

* 

* 

*/ 


# i fndef S0M_Modul e_somcust_Source 
#def i ne S0M_Modul e_somcust_Source 
#endi f 

#define S0MCustomer_Cl ass_Source 

#def i ne SOMMSi ngl eInstance_Cl ass_Source 

#include "SOMCust.xih" 

/* 

*Method from the IDL attribute statement: 

*"attribute SOMAccount* account" 

*/ 

S0M_Scope SOMAccount* SOMLINK _get_account (SOMCustomer *somSelf, 

Environment *ev) 

{ 

SOMCustomerData *somThis = SOMCustomerGetData(somSelf) ; 
SOMCustomerMethodDebug ("SOMCustomer", "_get_account") ; 

/* Always return the first account */ 

/* for compability purpose only */ 

/* FCE V 2 only support 1 account */ 
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// if no account for this customer, return a nil account 
if (sequenceLength (somThi s->accountList)==0) { 

SOMAccount *nil Account = new SOMAccount() ; 
ni 1 Account->_set_accountNumber(ev, " "); 
ni 1 Account->_set_bal ance(ev, 0.0) ; 

nilAccount->_set_accountDescription(ev,"no account found"); 
nilAccount->_set_branchId(ev, " "); 
return nilAccount; 

} 

else { 

SOMAccount *firstAccount = new S0MAccount( sequenceElement(somThis->accountList,0) ) 
return firstAccount; 

} 

} 


/* 

*Method from the IDL attribute statement: 

*"attribute SOMAccount* account" 

*/ 

S0M_Scope void SOMLINK _set_account(S0MCustomer *somSelf, Environment *ev, 

SOMAccount* account) 

{ 

SOMCustomerData *somThis = SOMCustomerGetData(somSelf) ; 
SOMCustomerMethodDebug("SOMCustomer","_set_account") ; 

/* ignored .... */ 

/* account information is set thruoug the SOMAccount object */ 


/* 

*Method from the IDL attribute statement: 

*"attribute string firstName" 

*/ 

S0M_Scope string SOMLINK _get_firstName(SOMCustomer *somSelf, 

Environment *ev) 

{ 

SOMCustomerData *somThis = SOMCustomerGetData(somSelf) ; 
SOMCustomerMethodDebug("SOMCustomer","_get_fi rstName") ; 

// just in case 

if (somThis->fi rstName == NULL) { 

somThi s->fi rstName = (string) SOMMal 1 oc (2) ; 
strcpy (somThis->fi rstName," "); 

} 

string firstName = (string) SOMMalloc(strlen(somThis->firstName)+l) 
strcpy (fi rstName, somThi s->fi rstName) ; 
return firstName; 


/* 

*Method from the IDL attribute statement: 

*"attribute string firstName" 
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*/ 

SOM_Scope void SOMLINK _set_fi rstName (SOMCustomer *somSelf, 

Environment *ev, string firstName) 

{ 

SOMCustomerData *somThis = SOMCustomerGetData(somSelf) ; 
SOMCustomerMethodDebug ("SOMCustomer", "_set_fi rstName") ; 


if (fi rstName!=NULL) { 

if (somThis->fi rstName != NULL) SOMFree(somThis->firstName) ; 
somThi s->fi rstName = (string) SOMMal loc(strlen(fi rstName)+l) ; 
strcpy(somThis->firstName, firstName) ; 

} 

else { 

// exception should be raised here 
// not implemented in our demo 

} 


/* 

*Method from the IDL attribute statement: 

*"attribute string lastName" 

*/ 

S0M_Scope string SOMLINK _get_l astName(SOMCustomer *somSelf, 

Environment *ev) 

{ 

SOMCustomerData *somThis = SOMCustomerGetData(somSelf) ; 
SOMCustomerMethodDebug ("SOMCustomer", "_get_l astName" ) ; 

if (somThi s->l astName == NULL) { 

somThi s->l astName = (string) S0MMalloc(2) ; 
strcpy(somThis->lastName," "): 

} 

string lastName = (string) SOMMal loc(strlen (somThi s->l astName)+l) ; 
strcpy (1 astName, somThi s->l astName) ; 
return lastName; 


/* 

*Method from the IDL attribute statement: 

*"attribute string lastName" 

*/ 

S0M_Scope void SOMLINK _set_l astName (SOMCustomer *somSelf, Environment *ev, 

string lastName) 

{ 

SOMCustomerData *somThis = SOMCustomerGetData(somSelf) ; 
SOMCustomerMethodDebug ("SOMCustomer", "_set_l astName" ) ; 

if (lastName!=NULL) { 

if (somThi s->l astName != NULL) SOMFree(somThi s->l astName) ; 
somThi s->l astName = (string) SOMMal 1 oc(strl en (1 astName)+l) ; 
strcpy (somThi s->l astName, 1 astName) ; 

} 

else { 
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// should raise exception here 
// not implemented in our demo 



/* 

*Method from the IDL attribute statement: 

*"attribute string homePhone" 

*/ 

S0M_Scope string SOMLINK _get_homePhone(SOMCustomer *somSelf, 

Environment *ev) 

{ 

SOMCustomerData *somThis = SOMCustomerGetData(somSelf) ; 
SOMCustomerMethodDebug("SOMCustomer","_get_homePhone") : 

if (somThi s->homePhone == NULL) { 

somThi s->homePhone = (string) SOMMal 1 oc (2) ; 
strcpy (somThi s->homePhone," "); 

} 

string homePhone = (string) SOMMalloc(strlen(somThis->homePhone)+l) ; 
strcpy (homePhone, somThi s->homePhone) ; 
return homePhone; 


/* 

*Method from the IDL attribute statement: 

*"attribute string homePhone" 

*/ 

S0M_Scope void SOMLINK _set_homePhone(SOMCustomer *somSelf, 

Environment *ev, string homePhone) 

{ 

SOMCustomerData *somThis = SOMCustomerGetData(somSelf) ; 
SOMCustomerMethodDebug("SOMCustomer","_set_homePhone") : 

if (homePhone!=NULL) { 

if (somThi s->homePhone != NULL) SOMFree(somThis->homePhone) ; 
somThi s->homePhone = (string) SOMMal loc(strlen(homePhone)+l) ; 
strcpy(somThis->homePhone, homePhone) ; 

} 

else { 

// should raise exception here 
// not implemented in our demo 

} 


/* 

*Method from the IDL attribute statement: 
*"attribute string workPhone" 

*/ 


S0M_Scope string 
{ 


SOMLINK _get_workPhone(SOMCustomer *somSelf, 
Environment *ev) 
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SOMCustomerData *somThis = SOMCustomerGetData(somSelf) ; 
SOMCustomerMethodDebug("SOMCustomer","_get_workPhone") ; 

if (somThi s->workPhone = NULL) { 

somThi s->workPhone = (string) SOMMal 1 oc (2) ; 
strcpy (somThi s->workPhone," "); 

} 

string workPhone = (string) SOMMalloc(strlen(somThis->workPhone)+l) ; 
strcpy (workPhone, somThi s->workPhone) ; 
return workPhone; 


/* 

*Method from the IDL attribute statement: 

*"attribute string workPhone" 

*/ 

S0M_Scope void SOMLINK _set_workPhone(SOMCustomer *somSelf, 

Environment *ev, string workPhone) 

{ 

SOMCustomerData *somThis = SOMCustomerGetData(somSelf) ; 
SOMCustomerMethodDebug("SOMCustomer","_set_workPhone") ; 


if (workPhone!=NULL) { 

if (somThi s->workPhone != NULL) SOMFree(somThis->workPhone) ; 
somThi s->workPhone = (string) SOMMalloc(strlen(workPhone)+l) ; 
strcpy(somThis->workPhone, workPhone) ; 

} 

else { 

// should raise exception here 
// not implemented in our demo 

} 


S0M_Scope string SOMLINK accountNum(SOMCustomer *somSelf, Environment *ev) 

{ 

SOMCustomerData *somThis = SOMCustomerGetData(somSelf) ; 
SOMCustomerMethodDebug("SOMCustomer","accountNum") ; 

/* same as account anyway */ 

return somSel f->_get_account(ev)->_get_accountNumber(ev) ; 


/* 

* Not used in current branch clients 
*/ 

S0M_Scope float SOMLINK accountBalance(SOMCustomer *somSelf, 

Environment *ev) 

{ 

SOMCustomerData *somThis = SOMCustomerGetData(somSelf) ; 
SOMCustomerMethodDebug("SOMCustomer","accountBal ance") : 
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/* return the account balance of the FIRST account only */ 
/* FCE V 2 only support 1 account */ 

return somSel f->_get_account(ev)->_get_balance(ev) ; 


/* 

*Method from the IDL attribute statement: 

*"attribute string street" 

*/ 

S0M_Scope string SOMLINK _get_street(SOMCustomer *somSelf, Environment *ev) 

{ 

SOMCustomerData *somThis = SOMCustomerGetData(somSelf) ; 
SOMCustomerMethodDebug("SOMCustomer","_get_street") ; 

if (somThi s->street == NULL) { 

somThi s->street = (string) SOMMal 1 oc(2) ; 
strcpy(somThis->street," "); 

} 

string street = (string) SOMMal loc(strl en(somThi s->street)+l) ; 
strcpy (street, somThi s->street) ; 
return street; 


/* 

*Method from the IDL attribute statement: 

*"attribute string street" 

*/ 

S0M_Scope void SOMLINK _set_street(SOMCustomer *somSelf, Environment *ev, 

string street) 

{ 

SOMCustomerData *somThis = SOMCustomerGetData(somSelf) ; 
SOMCustomerMethodDebug("SOMCustomer","_set_street") ; 


if (street!=NULL) { 

if (somThi s->street != NULL) SOMFree (somThi s->street) ; 
somThi s->street = (string) SOMMal loc(strlen(street)+l) ; 
strcpy(somThis->street, street); 

} 

else { 

// should raise exception here 
// not implemented in our demo 



/* 

*Method from the IDL attribute statement: 

*"attribute string city" 

*/ 

S0M_Scope string SOMLINK _get_city(SOMCustomer *somSelf, Environment *ev) 
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{ 

SOMCustomerData *somThis = SOMCustomerGetData(somSel f) ; 
SOMCustomerMethodDebug("SOMCustomer","_get_ci ty") ; 

if (somThis->city == NULL) { 

somThi s->city = (string) SOMMal 1 oc (2) ; 
strcpy(somThis->city," "); 

} 

string city = (string) SOMMal loc(strlen(somThis->city)+l) 
strcpy(city, somThi s->city) ; 
return city; 


/* 

*Method from the IDL attribute statement: 

*"attribute string city" 

*/ 

S0M_Scope void SOMLINK _set_city(SOMCustomer *somSelf, Environment *ev, 

string city) 

{ 

SOMCustomerData *somThis = SOMCustomerGetData(somSelf) ; 
SOMCustomerMethodDebug("SOMCustomer","_set_ci ty") ; 


if (ci ty ! =NULL) { 

if (somThi s->city != NULL) SOMFree(somThis->city) ; 
somThi s->ci ty = (string) SOMMal 1 oc(strl en (ci ty) +1) 
strcpy(somThis->city, city); 

} 

else { 

// should raise exception here 
// not implemented in our demo 

} 

} 


/* 

*Method from the IDL attribute statement: 

*"attribute string state" 

*/ 

S0M_Scope string SOMLINK _get_state(SOMCustomer *somSelf, Environment *ev) 

{ 

SOMCustomerData *somThis = SOMCustomerGetData(somSelf) ; 
SOMCustomerMethodDebug ("SOMCustomer","_get_state" ) ; 

if (somThi s->state == NULL) { 

somThi s->state = (string) SOMMal loc (2) ; 
strcpy (somThis->state," "); 

} 

string state = (string) SOMMal loc(strlen(somThi s->state)+l) ; 
strcpy (state, somThi s->state) ; 
return state; 


Figure 92 (Part 7 of 15). SOMCustomer Implementation 


210 Developing Distributed Object Applications 





/* 

*Method from the IDL attribute statement: 

*"attribute string state" 

*/ 

S0M_Scope void SOMLINK _set_state(SOMCustomer *somSelf, Environment *ev, 

string state) 

{ 

SOMCustomerData *somThis = SOMCustomerGetData(somSelf) ; 
SOMCustomerMethodDebug("SOMCustomer","_set_state") ; 


if (state!=NULL) { 

if (somThis->state != NULL) SOMFree(somThis->state) ; 
somThi s->state = (string) SOMMal 1 oc(strlen(state)+l) ; 
strcpy(somThis->state, state); 

} 

else { 

// should raise exception here 
// not implemented in our demo 



/* 

*Method from the IDL attribute statement: 

*"attribute string zip" 

*/ 

S0M_Scope string SOMLINK _get_zip(SOMCustomer *somSelf, Environment *ev) 

{ 

SOMCustomerData *somThis = SOMCustomerGetData(somSelf) ; 
SOMCustomerMethodDebug("SOMCustomer","_get_zip") ; 

if (somThi s->zip == NULL) { 

somThis->zip = (string) SOMMal 1 oc(2) ; 
strcpy(somThis->zip," "); 

} 

string zip = (string) SOMMal loc(strlen(somThis->zip)+l) ; 
strcpy(zip, somThi s->zi p) ; 
return zip; 


/* 

*Method from the IDL attribute statement: 

*"attribute string zip" 

*/ 

S0M_Scope void SOMLINK _set_zip(SOMCustomer *somSelf, Environment *ev, 

string zip) 

{ 

SOMCustomerData *somThis = SOMCustomerGetData(somSelf) ; 
SOMCustomerMethodDebug("SOMCustomer","_set_zip") ; 


if (zip! =NULL) { 

if (somThis->zip != NULL) SOMFree(somThi s->zip) ; 
somThis->zip = (string) SOMMal loc(strl en(zip)+l) ; 
strcpy(somThis->zip, zip); 
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else { 

// should raise exception here 
// not implemented in our demo 


*Method from the IDL attribute statement: 

*"attribute string accountld" 

*/ 

S0M_Scope string SOMLINK _get_accountId(SOMCustomer *somSelf, 

Environment *ev) 

{ 

SOMCustomerData *somThis = SOMCustomerGetData(somSelf) ; 
SOMCustomerMethodDebug ("SOMCustomer","_get_account Id" ) ; 

if (somThi s->accountId == NULL) { 

somThi s->accountId = (string) S0MMalloc(2) ; 
strcpy (somThi s->account Id," "); 


string accountld = (string) SOMMalloc(strlen(somThis->accountId)+l) ; 
strcpy (accountld, somThi s->accountId) ; 
return accountld; 


*Method from the IDL attribute statement: 

*"attribute string accountld" 

*/ 

S0M_Scope void SOMLINK _set_accountId(SOMCustomer *somSelf, 

Environment *ev, string accountld) 

{ 

SOMCustomerData *somThis = SOMCustomerGetData(somSelf) ; 
SOMCustomerMethodDebug("SOMCustomer","_set_accountId") ; 


if (accountId!=NULL) { 

if (somThi s->accountId != NULL) SOMFree(somThis->accountId) ; 
somThi s->accountId = (string) SOMMal loc(strlen(accountId)+l) ; 
strcpy(somThis->accountId, accountld) ; 

} 

else { 

// should raise exception here 
// not implemented in our demo 


S0M_Scope _IDL_SEQUENCE_SOMAccount SOMLINK accounts (SOMCustomer *somSelf, 

Environment *ev) 

{ 

SOMCustomerData *somThis = SOMCustomerGetData(somSelf) ; 
SOMCustomerMethodDebug ("SOMCustomer", "accounts") ; 
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// the list of all accounts to be return 
_IDL_SEQUENCE_SOMAccount returnAccountLi st ; 

// prepare for inserting into the return list 

int numAccounts = sequencel_ength(somThi s->accountLi st) ; 

sequenceMaximum(returnAccountLi st) = numAccounts; 

somThis->accountList._buffer = (SOMAccount **)S0MMal loc(sizeof (SOMAccount *) * numAccounts); 

// actual insertion logic 

sequenceLength (returnAccountLi st) = 0; 

for (int counter=l;counter<=numAccounts; counter++) { 

sequenceElement(returnAccountList, counter-1) = 

new SOMAccount(sequenceElement(somThis->accountList, counter-1)) ; 

++sequenceLength (returnAccountLi st) ; 

} 

return returnAccountLi st; 


/* 

* retrieve information about myself, based on the customerld I have 
*/ 

S0M_Scope void SOMLINK retrieve(SOMCustomer *somSelf, Environment *ev) 

{ 

SOMCustomerData *somThis = SOMCustomerGetData(somSelf) ; 
SOMCustomerMethodDebug("SOMCustomer"," retrieve") ; 

DaxCust DAXCustomerObject; 

// retrieve a customer from database with the customer id 
try { 

DAXCustomerObject.setCust_id( somThi s->customerId ); 

DAXCustomerObject. retrieve() ; 

} 

catch (I Except ion &exc) { 
somPrintf ("Error id: %d\n", exc.errorldO ); 
for (unsigned long i = 0; i < exc.textCount() ; i++) 
somPrintf ("Error Text: %s\n", exc.text(i) ); 
somPrintf ("Error Class: %s\n", exc.name() ); 

// set exception to client program 

// not implemented in the SmallTalk part, so remmed here 
// SOMCustomer_Excep *myExcept 

// = (SOMCustomer_Excep *)S0MMal loc(sizeof (SOMCustomer_Excep)) ; 

// myExcept->errCode = RETRIEVE_PROBLEM; 

// strcpy (myExcept->reason, "Customer cannot be retrieved"); 

// somSetException(ev, USER_EXCEPTION, ex_SOMCustomer_Excep, (void *)myExcept) ; 

// return; 

somSel f->_set_firstName(ev," ") ; 
somSel f->_s e t_l astName(ev," ") ; 
somSel f->_set_homePhone(ev," "); 
somSel f->_set_workPhone(ev," "); 
somSel f->_set_street(ev," "); 
somSel f->_set_city(ev," "); 
somSel f->_set_state(ev," "); 
somSel f->_set_zip(ev," "); 
somSel f->_set_accountId(ev," "); 
return; 

} 

somSel f->_set_fii"stName(ev,DAXCustomerObject.cust_fname() ) ; 
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somSel f->_set_l ast Name (ev, DAXCus tomerObj ect. cus t_l name () ) ; 
somSel f->_set_homePhone (ev , DAXCustomerObj ect . cust_hphone () ) ; 
somSel f->_set_workPhone (ev , DAXCustomerObj ect . cus t_wphone ( ) ) ; 
somSel f->_set_street (ev, DAXCustomerObj ect .cust_street ()) ; 
somSel f->_set_ci ty (ev, DAXCustomerObj ect. cus t_ci ty ()) ; 
somSel f->_set_state(ev, DAXCustomerObj ect. cus t_state() ) ; 
somSel f->_set_zi p(ev, DAXCustomerObj ect .cust_zi p()) ; 
somSel f->_set_accountId(ev, DAXCustomerObj ect .cust_acid()) ; 

// somSel f->getAl 1 AccountldsForSel f (ev) ; 
somSel f->getAl 1 AccountsForSel f (ev) ; 

} 


/* 

* update my information to the persi stance storage 
*/ 

S0M_Scope void SOMLINK update(SOMCustomer *somSelf, Environment *ev) 

{ 

SOMCustomerData *somThis = SOMCustomerGetData (somSel f) ; 
SOMCustomerMethodDebug ("SOMCustomer", " update" ) ; 

DaxCust DAXCustomerObj ect; 

DaxAcct DAXAccountObject; 

// update the customer with the current id 
try { 

DAXCustomerObj ect. setCust_id (somThi s->customerId) ; 

DAXCustomerObject.setCust_fname (somThi s->firstName ); 
DAXCustomerObject.setCust_lname (somThi s->lastName ); 
DAXCustomerObject.setCust_hphone(somThi s->homePhone ) ; 

DAXCus tomerOb j ect. setCust_wphone (somThi s->homePhone ) ; 

DAXCus tomerObj ect. setCust_street (somThi s->street ) ; 
DAXCustomerObject.setCust_city (somThi s->city ); 
DAXCustomerObject.setCust_state (somThi s->state ); 
DAXCustomerObject.setCust_zip (somThi s->zi p ); 

/* following line might need to be modified */ 

DAXCus tomerObj ect. setCust_acid (somThi s->accountId) ; 

DAXCustomerObject.update() ; 

// commit immediately, this is a demo anyway. 

DSObject.commit() ; 

} catch (IException &exc) { 
somPrintf ("Error id: %d\n", exc.errorldO ); 
for (unsigned long i = 0; i < exc.textCount() ; i++) 
somPrintf ("Error Text: %s\n", exc.text(i) ); 
somPrintf ("Error Class: %s\n", exc.name() ); 

} 


/* 

* add myself to the customer list 
*/ 

S0M_Scope void SOMLINK add (SOMCustomer *somSelf, Environment *ev) 

{ 

SOMCustomerData *somThis = SOMCustomerGetData (somSel f) ; 
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SOMCustomerMethodDebug ("SOMCustomer", "add") ; 

DaxCust DAXCustomerObject; 

// put all necessary information to the data access object 
DAXCustomerObject.setCust_id (somThi s->customerId) ; 
DAXCustomerObject. setCust_fname (somThi s->fi rstName ); 
DAXCustomerObject. setCust_l name (somThi s->lastName ); 
DAXCustomerObject. setCust_hphone (somThi s->homePhone ) ; 
DAXCustomerObject. setCust_wphone(somThis->homePhone ) ; 
DAXCus tomerOb j ect. setCus t_street( somThi s->street ) ; 

DAXCustomerObject.setCust_city (somThi s->city ); 
DAXCustomerObject.setCust_state (somThi s->state ); 
DAXCustomerObject.setCust_zip (somThi s->zip ); 

DAXCustomerObject.setCust_acid (somThi s->accountId ); 

// note that the customer does not has any account yet 

// add a customer to the database 
try { 

DAXCustomerObject.add() ; 

// commit immediately, this is a demo anyway. 
DSObject.commit() ; 


} 

catch (I Except ion &exc) { 
somPrintf ("Error id: %d\n", exc.errorldO ); 
for (unsigned long i = 0; i < exc.textCount() ; i++) 
somPrintf ("Error Text: %s\n", exc.text(i) ); 
somPrintf ("Error Class: %s\n", exc.name() ); 

} 


/* 

* delete myself from the customer list. Also all accounts belonged to me 

* wi 1 1 be deleted 
*/ 

S0M_Scope void SOMLINK del (SOMCustomer *somSelf, Environment *ev) 

{ 

SOMCustomerData *somThis = SOMCustomerGetData(somSelf) ; 
SOMCustomerMethodDebug ("SOMCustomer", "remove") ; 

DaxCust DAXCustomerObject; 

// remove a customer from the database with the current customer id 
try { 

int numAccount = sequenceLength (somThi s->accountLi st) ; 
for (int counter=l; counter <= numAccount; counter++) { 

if (sequenceElement(somThis->accountList, counter-1) ! =NULL) { 
sequenceElement(somThis->accountList, counter-1) ->del (ev); 
delete sequenceElement(somThis->accountList, counter-1); 

} 


if (somThis->accountList._buffer != NULL) SOMFree(somThis->accountList. 
somThi s->accountLi st._buffer = NULL; 

DAXCustomerObject.setCust_id( somThi s->customerId ); 
DAXCustomerObject.de! () ; 

// commit immediately, this is a demo anyway. 

DSObject.commit() ; 
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} 

catch (I Except ion &exc) { 
somPrintf ("Error id: %d\n", exc.errorldO ); 
for (unsigned long i = 0; i < exc.textCount() ; i++) 
somPrintf ("Error Text: %s\n", exc.text(i) ); 
somPrintf ("Error Class: %s\n",exc.name() ); 

} 


S0M_Scope void SOMLINK getAl 1 AccountsForSel f (SOMCustomer *somSelf, 

Environment *ev) 

{ 

SOMCustomerData *somThis = SOMCustomerGetData(somSelf) ; 
SOMCustomerMethodDebug ("SOMCustomer", "getAl 1 AccountsForSel f") ; 

/* 

* retrieve all accounts for this customer codes here 
*/ 

/* 
if 


} 

/* now construct a new 1st */ 

int numAccounts = 1; //I because FCE only has 1 account 

somThis->accountList._buffer = (SOMAccount **) SOMMal loc(sizeof (SOMAccount *) * numAccounts ); 

// demo only. DaxAcctMgrObject should be used. 
sequenceLength(somThis->accountList) = 0; 
for (int counter=l; counter<=numAccounts; counter++) { 
sequenceElement(somThis->accountList, counter-1) = 
new SOMAccount () ; 

/* following line might need to be modified */ 

sequenceElement(somThis->accountList,counter-l)->_set_accountNumber(ev,somThis->accountId) ; 
sequenceElement(somThis->accountList,counter-l)->retrieve(ev) ; 

++sequenceLength (somThi s->accountLi st) ; 

} 


S0M_Scope void SOMLINK getAl 1 AccountldsForSel f (SOMCustomer *somSelf, 

Environment *ev) 

{ 

SOMCustomerData *somThis = SOMCustomerGetData(somSelf) ; 
SOMCustomerMethodDebug ("SOMCustomer", "getAl 1 AccountsForSel f") ; 

/* 

* retrieve all accounts for this customer codes here 
*/ 


/* first forget all account list this customer has */ 
if (sequenceLength(somThis->accountIdList)>0) { 
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first forget all account list this customer has */ 

(sequence Length (somThi s->account Li st) >0) { 

int originalAccountNums = sequenceLength (somThi s->accountLi st) ; 
for (int counter=l; counter<=originalAccountNums; counter++) { 
delete sequenceElement(somThis->accountList, counter-1); 

} 

i f (somThi s->accountList._buffer!=NULL) 

SOMFree (somThi s->accountLi st._buffer) ; 
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int originalAccountNums = sequenceLength(somThis->accountIdList) ; 
for (int counter=l; counter<=originalAccountNums; counter++) { 

SOMFree(sequenceEl ement (somThis->accountIdLi st, counter- 1)) ; 

} 

if (somThis->accountIdLi st._buffer!=NULL) 

SOMFree(somThis->accountIdLi st._buffer) ; 

} 

/* now construct a new 1st */ 

int numAccounts = 1; //I because FCE only has 1 account 

somThis->accountIdList._buffer = (string *) SOMMalloc(sizeof(string *) * numAccounts ) 

// demo only. DaxAcctMgrObject should be used. 
sequenceLength(somThis->accountIdList) = 0; 
for (int counter=l; counter<=numAccounts; counter++) { 
sequenceElement(somThis->accountIdl_ist, counter-1) - 
(string) SOMMal loc(strl en(somThi s->accountId)+l) ; 

/* following line might need to be modified */ 

strcpy(sequenceElement(somThi s->accountIdList , counter- 1) ,somThis->accountId) ; 
++sequenceLength(somThis->accountIdLi st) ; 

} 

} 


S0M_Scope void SOMLINK somDestruct (SOMCustomer *somSelf, octet doFree, 

somDestructCtrl* Ctrl) 

{ 

SOMCustomerData *somThis; /* set in Begi nDestructor */ 
somDestructCtrl global Ctrl; 
somBooleanVector myMask; 

SOMCustomerMethodDebug ("SOMCustomer", "somDestruct") ; 
SOMCustomer_Begi nDestructor; 

/* 

* local SOMCustomer deinitialization code added by programmer 
*/ 

SOMCustomer_EndDestructor; 

somPrintf ("%d is destructed. . ,\n", somSelf); 


S0M_Scope void SOMLINK somDefaultlnit (SOMCustomer *somSelf, somlnitCtrl* Ctrl) 

{ 

SOMCustomerData *somThis; /* set in Begi nlnitial izer */ 
somlnitCtrl global Ctrl; 
somBooleanVector myMask; 

SOMCustome rMethodDebug ("SOMCustomer", "somDefault I nit") ; 
SOMCustomer_BeginIni tial izer_somDefaul tlni t; 

SOMCustomer_Ini t_SOMObject_somDefaul tlni t (somSel f , Ctrl ) ; 

/* 

* local SOMCustomer initialization code added by programmer 
*/ 

sequenceMaximum(somThis->accountList) = 20; 
sequenceLength(somThis->accountList) = 0; 
sequenceMaximum(somThis->accountIdLi st) = 20; 
sequenceLength(somThis->accountIdList) = 0; 


S0MEXTERN void SOMLINK S0MInitModule( long majorVersion, 
Figure 92 (Part 14 of 15). SOMCustomer Implementation 


Appendix E. SOM Objects Implementation Files 217 





long minorVersion, 
string className) 


S0MCustomerNewClass(0,0) ; 

/* 

* local dTstCust initialization code added by programmer 
*/ 

try { 

DSObject. connect ("CSOODB", "FCE", "PASSWORD"); 

} catch (IException &exc) { 
somPrintf("Failed: Exception occurs\n"); 
somPrintf ("Error id: %ld\n", exc.errorldO ) ; 
for (unsigned long i = 0; i < exc.textCount() ; i++) 
somPrintf ("Error Text: %s\n", exc.text(i) ); 
somPrintf ("Error Class: %s\n", exc.nameO); 

} 


somPri ntf ^ // *************************\p / 

) 


somPrintf ("* 

SOM CUSTOMER SERVER 

*\n' 

) 


somPrintf ("* 

initial ized 

*\n' 

) 


somPrintf ("* 

and connected to 

*\n' 

) 


somPrintf ("* 

CSOODB 

*\n' 

) 


somPrintf ("* 


*\n' 

) 


somPrintf ("* 

ready to serve 

*\n' 

) 


somPrintf ("* 

client request. . . 

*\n' 

) 


somPrintf ("* 


*\n' 

) 


somPri ntf ^ // *************************\p\p // ) • 


Figure 92 (Part 15 of 15). SOMCustomer Implementation 


E.5 SOMCustomerManager Implementation 


/* 

* This file was generated by the SOM Compiler. 

* Generated using: 

* SOM incremental update: 2.42 
*/ 

#define INCL_D0S 
#include <os2.h> 

/* 

* This file was generated by the SOM Compiler and Emitter Framework. 

* Generated using: 

* SOM Emitter emitxtm: 2.42 
*/ 

#i fndef S0M_Modul e_somcmgr_Source 
#def i ne S0M_Modul e_somcmgr_Source 
#endi f 

#def i ne SOMCustomerManager_Cl ass_Source 
#def i ne SOMMSi ngl eInstance_Cl ass_Source 

#include "SOMCMgr.xih" 


Figure 93 (Part 1 of 4). SOMCustomerManager Implementation 
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SOM_Scope void SOMLINK refresh (SOMCustomerManager *somSelf, 

Environment *ev) 

{ 

/* SOMCustomerManagerData *somThis = SOMCustomerManagerGetData(somSel f) ; */ 
SOMCustomerManagerMethodDebug ("SOMCustomerManager", " ref resh" ) ; 
DAXMgrObject.refresh() ; 

DAXMgrObj ect . i terns () ->setToFi rst (cursor) ; 


S0M_Scope void SOMLINK select (SOMCustomerManager *somSelf, Environment *ev) 

{ 

/* SOMCustomerManagerData *somThis = SOMCustomerManagerGetData(somSel f) ; */ 
SOMCustomerManagerMethodDebug ("SOMCustomerManager", "select") ; 


S0M_Scope long SOMLINK numCustomers (SOMCustomerManager *somSelf, 

Environment *ev) 

{ 

/* SOMCustomerManagerData *somThis = SOMCustomerManagerGetData(somSel f) ; */ 
SOMCustomerManagerMethodDebug ("SOMCustomerManager", "numCustomers") : 

1 ong retVal ; 

retVal = DAXMgrObject. i terns () ->numberOfEl ements () ; 
return retVal ; 


S0M_Scope long SOMLINK takeFirstCustomerld (SOMCustomerManager *somSelf, 

Environment *ev) 

{ 

/* SOMCustomerManagerData *somThis = SOMCustomerManagerGetData(somSel f) ; */ 
SOMCustomerManagerMethodDebug ("SOMCustomerManager", "takeFi rstCustomerld") ; 

1 ong retVal ; 

if (!DAXMgrObject.items()->isEmpty()) { 

retVal = DAXMgrObject ,i tems()->fi rstElement()->cust_id() ; 
return retVal ; 

} 

else { 

return 0; 



S0M_Scope long SOMLINK takeLastCustomerld (SOMCustomerManager *somSelf, 

Environment *ev) 

{ 

/* SOMCustomerManagerData *somThis = SOMCustomerManagerGetData(somSel f) ; */ 
SOMCustomerManagerMethodDebug ("SOMCustomerManager", "takeLastCustomerld") ; 

1 ong retVal ; 

if (!DAXMgrObject.items()->isEmpty()) { 

retVal = DAXMgrObject ,i tems()->lastElement() ->cust_id() ; 
return retVal ; 

} 

else { 

return 0; 



S0M_Scope long SOMLINK takeNextCustomerld (SOMCustomerManager *somSelf, 

Environment *ev) 

{ 

/* SOMCustomerManagerData *somThis = SOMCustomerManagerGetData(somSelf) ; */ 
SOMCustomerManagerMethodDebug ("SOMCustomerManager", "takeNextCustomerld") ; 

1 ong retVal ; 


Figure 93 (Part 2 of 4). SOMCustomerManager Implementation 
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if (!DAXMgrObject.items()->isEmpty() && !DAXMgrObject.items()->isLast(cursor) ) { 
// if ( IDAXMgrObject.i terns ()->is Empty ()) { 

// if ( DAXMgrObject. items()->isLast(cursor) ) { 

// retVal = somSel f->takeLastCustomerId(ev) ; 

// } 

// else { 

DAXMgrObject . i terns ()->setToNext (cursor) ; 

retVal = DAXMgrObject. items()->elementAt(cursor)->cust_id() ; 

// } 

return retVal ; 

} 

else { 

return 0; 

} 


S0M_Scope long SOMLINK takePreviousCustomerld (SOMCustomerManager *somSelf, 

Environment *ev) 

{ 

/* SOMCustomerManagerData *somThis = SOMCustomerManagerGetData(somSel f) ; */ 
SOMCustomerManagerMethodDebug ("SOMCustomerManager", "takePreviousCustomerld") ; 

1 ong retVal ; 

if (!DAXMgrObject.items()->isEmpty() && IDAXMgrObject.i terns ()->isFirst (cursor) ) { 
// if (! DAXMgrObj ect. i terns ()->is Empty () ) ( 

// if ( DAXMgrObject. items()->isFirst(cursor) ) { 

// retVal = somSelf->takeFirstCustomerId(ev) ; 

// } 

// else { 

DAXMgrObject . i terns ()->setToPrevious (cursor) ; 

retVal = DAXMgrObject. items()->elementAt(cursor)->cust_id() ; 

// } 

return retVal ; 

} 

else { 

return 0; 

} 


S0M_Scope void SOMLINK somDestruct(SOMCustomerManager *somSelf, 

octet doFree, somDestructCtrl* Ctrl) 

{ 

SOMCustomerManagerData *somThis; /* set in BeginDestructor */ 
somDestructCtrl global Ctrl; 
somBooleanVector myMask; 

SOMCustomerManagerMethodDebug ("SOMCustomerManager", " somDestruct" ) ; 
SOMCustomerManager_Begi nDestructor; 

/* 

* local SOMCustomerManager deinitialization code added by programmer 
*/ 

SOMCustomerManager_EndDestructor; 

} 


S0M_Scope void SOMLINK somDefaultInit(SOMCustomerManager *somSelf, 

somlnitCtrl* Ctrl) 

{ 

SOMCustomerManagerData *somThis; /* set in Beginlnitial izer */ 
somlnitCtrl gl obal Ctrl ; 
somBooleanVector myMask; 

SOMCustome rManagerMethodDebug ("SOMCustomerManager", "somDefaul tin it") 
SOMCustomerManager_BeginIni tial izer_somDefaul tlni t ; 

SOMCustomerManager_Ini t_S0M0bject_somDefaul tlni t (somSel f , Ctrl ) ; 

Figure 93 (Part 3 of 4). SOMCustomerManager Implementation 
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/* 

* local SOMCustomerManager initialization code added by programmer 
*/ 


SOMEXTERN void SOMLINK SOMInitModule( long majorVersion, 

long minorVersion, 
string className) 


SOMCustomerManagerNewCl ass (0 , 0) ; 

/* 

* local dTstCust initialization code added by programmer 
*/ 

try { 

DSObject. connect ("CS00DB", "FCE", "PASSWORD"); 

} catch (IException &exc) { 
somPrintf("Failed: Exception occurs\n"); 
somPrintf ("Error id: %ld\n", exc.errorldO) ; 
for (unsigned long i = 0; i < exc.textCount() ; i++) 
somPrintf ("Error Text: %s\n", exc.text(i) ); 
somPrintf ("Error Class: %s\n", exc.nameO); 

} 


Figure 93 (Part 4 of 4). SOMCustomerManager Implementation 
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List of Abbreviations 


API 

application programming interface 

BOA 

basic object adapter 

CRC 

class-responsibility-collaboration 

CORBA 

Common Object Request Broker 
Architecture 

CUA 

Common User Access 

DCE 

Distributed Computing Environment 

DFS 

Distributed File System (an OSF DCE 
component) 

DLL 

dynamic link library (OS/2) 

DRDA 

Distributed Relational Database 

Architecture 

DSOM 

Distributed System Object Model 

DTP 

distributed transaction processing 

DTS 

Direct-To-SOM 

ESIOP 

environment-specific inter-ORB protocol 

FCE 

foreign currency exchange 

FIFO 

first-in first-out 

GIOP 

general inter-ORB protocol 

GSS 

Generic Security Services 

GUI 

graphical user interface 

IBM 

International Business Machines 
Corporation 

IDL 

interface definition language 

hop 

Internet inter-ORB protocol 

IOP 

inter-ORB protocol 

IP 

Internet Protocol 

IPC 

inter-process communication 

IPMD 

IBM Presentation Manager debugger 


ITSO 

International Technical Support 
Organization 

LAN 

local area network 

LIFO 

last-in first-out 

NCS 

NetWork Computing System 

NFS 

NetWork File System 

NetSP 

Network Security Program 

OMA 

object management architecture 

OMG 

Object Management Group 

OMT 

object modeling technique 

OOSE 

object-oriented software engineering 

ORB 

object request broker 

OSF 

Open Systems Foundation 

OSI 

open systems interconnection 

OTS 

object transaction service 

PDS 

persistent data store 

PID 

persistent identifier 

POM 

persistent object manager 

POS 

persistence object service (SOM) 

PM 

Presentation Manager (OS/2) 

RDBMS 

relational database management system 

RDD 

responsibility driven design 

RPC 

remote procedure call 

SOM 

System Object Model 

SPI 

service provider interface 

TLS 

two-level store (OMG Persistence 

Service) 

TP 

transaction program/process (OSI) 

UNO 

Universal Networked Objects (CORBA 2.0) 

VMT 

Visual Modeling Technique 


© Copyright IBM Corp. 1996 


223 



224 Developing Distributed Object Applications 



Index 


A 
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object-oriented 93 
API method 
application 

design of distribution 99 
VisualAge application 102 
architecture 

application 100 

B 

benefits 

binding 

binding files 128 
bridge 

full bridge 32 
half bridge 32 

c 

C + + 124 

CICS OS/2 18 
class 

attributes 126 
description in IDL 126 
relationships 126 
client 

design considerations 109 
functions 138 
implementation 138 
side 114 
client/server 

evolution of 17 
styles 4 

Common Object Request Broker Architecture 23 
computing 3 
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CORBA 1.2 30 

CORBA 2.0 29 

CORBA 2.0 interoperability protocols 32 
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CORBA-defined data types 42 
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CORBA2/C 30 
CORBA2/C + + 30 

CORBA2/CORE 30 
CORBA2/IIOP 30 
CORBA2/lnteroperable 30 
CORBA2/Smalltalk 30 


CORBA (continued) 

CORBAservices 25 
IDL 36,42 

interface repository 42 
link between CORBA and DCE 43 
OTS 23 
standard 54 

D 

data 

centralized 8 
partitioned 10 
replicated 9 
delegation 113 
design 

object 99 
object-oriented 93 
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system design 100 
Direct-to-SOM 
See DTS 
distributed 
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distributed objects 16 
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Distributed SOM 
architecture 49 
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workgroup support 44, 45 
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distributed systems 
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examples of building 7 


© Copyright IBM Corp. 1996 


225 



distributed transaction processing 23 
distribution toolkit 69 
distribution tools 
DRDA 19 

DSOM Implementation Repository 125 
DTP distributed transaction processing 23 
DTS 80, 81 

E 

encapsulation 17 
environment variables 
ETC 163 
HOSTNAME 163 
SOMDDIR 48 
SOMIR, remove it. 163 
SOMSOCKETS 163 
USER 163 
events 

concurrent 5 
independent 5 
evolution 

of object-oriented implementation 17 
exchange rate management 91 

F 

fat client 19 
FCE application 

extension scenarios 90 
Foreign Currency Exchange 87 
requirement specifications 87 
foreign currency exchange application 
See FCE application 
Framework 

Persistence 153 

G 

geographical locations 100 
golden rules 

H 

high traffic 19, 90 

I 

IBM system object model 35 
IDL 

class interface creation 124 
IDL stubs 
client 28 

implementation 123, 161, 164 
inheritance 112 
interoperability 153 
ISO OSI-TP standard 23 


L 

late binding 1 1 5 
layering 

logical object space 103 

M 

manifest data type 

See location-independent data type 
mapping 

subsystems to applications 103 
methodolody 
modeling 

object-oriented 93 

N 

name server 

network related topics 100 

o 

object 

initialization 127 
management 23 
persistence 118, 119 
to database mapping 119 
object design 99 
object management 23 
Object Management Architecture (OMA) 
Object Management Group 23 
See also OMG 

Object Management Group (OMG) 23 
object persistence design 99 
object reference 
object request broker 
See ORB 
object services 

currency service 61 
event service 60 
externalization service 61 
life cycle service 60 
naming service 60 
object transaction service 61 
persistence service 59 
security service 61 
object space 

boundaries 103 
candidates 103 
logical 103 
physical 103 

Object Transaction Service 23 
objects 

distributed 3, 15, 63 
OMG 23, 24, 31 

CORBA-compliant 1 

Object Model 26 

object transaction service 61 
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POS 119 
optimization 
ORB 27 

OS/2 Workplace Shell 66 
refid. corba.IDL 66 
OTS 61 
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passive server 20 
peer-to-peer 21 , 91 
performance 

See optimization 
persistence 

SOM support 119 
persistence manager 118 
physical object space 103 
prerequisites 
processing 

centralized 11 
partitioned 12 
replicated 11 
prototype 
proxy 47, 48, 49 
publish/subscribe scenario 20 

Q 

quick tour 

R 

recommendations 

reference 

See object reference 
relationship 

many-to-many 126 
one-to-many 126 
one-to-one 126 
reliability 100 
reusability 17 

s 

sample application 
sample code 
security 100 
server 

classes 114 
implementation 124 
setup 

Smalltalk 30, 34, 35, 36, 40, 41, 50, 139, 141, 144, 
145, 146, 147, 148, 151 
SOM 35, 39, 60 

collection classes 56 
Direct-to-SOM 71,78,80,81 
DSOM framework 43, 44 
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emitter framework 55 
event manager framework 53 
persistence framework 52 

release-to-release binary compatibility (RRBC) 41 
replication framework 43, 50 
somDefaultlnit 127 
SOMOA 48 

SOM Interface Repository 125 
SOMobjects xv, 42, 50, 56, 57, 58, 59, 60, 71, 73 
SOMsupport 63, 64, 65, 66, 138, 144, 145, 146, 151, 
153, 166 

SQL 18, 19, 118, 120, 121 

standards for distributed object computing 23 
stored procedure 19 
stub DLLs 128 
create 149 
subsystem 102 
system architecture 100 
system design 99, 100 
system object model 
See SOM 

T 

TCP/IP 29 

test environment 150 
testing strategies 
transportable data type 

See location-independent data type 
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See optimization 

u 

UNI 

See uniqueness of instances 
uniqueness of instances 
UNO 29 

V 

Visual Modeling Technique 87 
See also VMT 
VMT 94 

See also visual modeling technique 
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wrapper classes 138, 139, 141, 150, 151 
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